Évaluer ce que l’IA apporte à votre équipe de développement

Imaginons une équipe qui essaie une IA pour ajouter une fonctionnalité à son logiciel de suivi des interventions. Une responsable des opérations veut récupérer les interventions terminées dans le mois dans un fichier qu’elle pourra utiliser dans Excel. L’IA écrit rapidement le code qui produit le fichier CSV, un format compatible avec les tableurs.

Un développeur examine ensuite les lignes du fichier, corrige une règle de traitement des dates et teste les droits d’accès des entreprises clientes. Pour décider d’utiliser davantage l’IA, l’équipe doit mesurer le temps et le coût de l’ensemble de ce travail. La vitesse de programmation n’en représente qu’une partie.

Un essai limité, souvent appelé projet pilote, doit répondre à une question précise : pour ce type de demande, l’équipe peut-elle produire un logiciel qui répond aux exigences avec moins de travail ou des délais plus courts, à un coût justifié?

Choisir une demande que l’on peut évaluer

Définissez le besoin et les critères de qualité avant de commencer. Ici, le fichier doit contenir les bonnes interventions, respecter la séparation des dossiers des entreprises et signaler clairement les échecs de téléchargement. Précisez qui pourra trancher les cas ambigus.

Une fonctionnalité connue n’est pas forcément sans risque : un téléchargement peut exposer des renseignements sensibles. Commencez avec des données fictives, dans un environnement distinct de l’application utilisée par les clients.

Si personne ne peut décrire le résultat attendu, ou si la version d’essai ne démarre pas, il peut être nécessaire de résoudre ce problème en premier. Comparez aussi des solutions plus simples : améliorer la procédure de vérification, réutiliser une fonctionnalité existante ou limiter l’assistance de l’IA à une partie du travail.

Examiner le travail habituel avant le projet pilote

Étudiez des demandes comparables déjà réalisées : ce qui a été livré, le temps de programmation, les vérifications, les corrections et l’attente. Mentionnez les cas difficiles et les demandes exclues de la comparaison.

Appliquez les mêmes exigences au projet pilote. Comparer une petite correction générée par l’IA à une fonctionnalité complexe développée auparavant ne permet pas d’établir un gain. Si vous n’avez observé que quelques demandes, présentez les résultats comme un premier échantillon et précisez ses limites.

Les indicateurs de livraison logicielle de DORA examinent conjointement la rapidité de livraison et la stabilité. Pour cet essai, choisissez les mesures utiles à votre décision, sans laisser un indicateur de vitesse masquer le travail de correction.

Maintenir les exigences essentielles de qualité

Un délai plus court ne compense pas l’accès aux dossiers d’une autre entreprise. Avant l’essai, définissez les résultats inacceptables et les conditions à remplir pour rendre la fonctionnalité accessible aux clients.

Ce que l’essai doit établir	Renseignements à conserver
La fonctionnalité répond au besoin	Résultat attendu et fichier réellement téléchargé
Les erreurs importantes sont détectées	Vérifications exécutées et versions refusées
Les limites d’accès sont respectées	Actions autorisées et tentatives interdites effectivement bloquées
L’équipe peut remédier à un échec	Procédure mise à l’essai et responsable du rétablissement
Le travail total reste acceptable	Préparation, programmation, vérifications, corrections et soutien
L’organisation peut continuer à utiliser l’outil	Coûts récurrents et personnes responsables de la mise à jour des règles et des tests

Cette grille est une méthode proposée pour préparer une décision, pas un système de notation validé. Une condition qui n’a pas été vérifiée reste inconnue; elle n’est pas considérée comme remplie par défaut.

Compter aussi les tentatives infructueuses

Comptabilisez les coûts d’utilisation du modèle, les outils d’exécution et le travail humain. Distinguez la préparation initiale des dépenses récurrentes, en conservant les deux dans le bilan. Les versions rejetées, les nouvelles tentatives et les incidents attribuables à l’essai font partie du coût.

Pour des demandes de taille comparable, le calcul suivant peut être utile :

Coût par modification acceptée = coût total de l’essai ÷ nombre de modifications répondant aux critères convenus.

Si aucune modification n’est acceptée, indiquez le montant dépensé et ce résultat. Le ratio ne peut pas être calculé. Évitez de découper artificiellement une demande en plusieurs petites modifications pour améliorer la moyenne.

Le temps libéré peut permettre à l’équipe de traiter d’autres demandes sans réduire ses dépenses. L’article sur le temps gagné avec l’IA explique comment distinguer cette capacité supplémentaire d’une économie financière.

Fonder la décision sur les observations

Si les fonctionnalités répondent au besoin, que le travail total diminue et que l’équipe sait gérer les échecs, elle peut proposer un essai un peu plus large. Précisez alors les nouvelles demandes confiées à l’IA et les contrôles qui resteront nécessaires.

Si l’IA produit du code utile mais perd du temps à cause d’un environnement défaillant, la prochaine étape peut être d’améliorer cet environnement. Définissez ce que l’équipe observera lors d’un nouvel essai pour déterminer si la correction a aidé.

Si le travail de vérification et de correction dépasse les gains observés, il peut être raisonnable de réserver l’IA à une tâche plus limitée ou d’arrêter cette approche. Conservez les raisons de cette décision pour que les essais suivants tiennent compte de ce qui a été appris.

La décision doit prendre en compte la qualité des tests, les droits d’accès accordés et le travail de rétablissement. Un changement de modèle ou d’outil peut nécessiter de réexaminer ces conditions.

Un Sprint d’opportunité peut étudier une incertitude définie avec vous et produire une note d’aide à la décision. La portée, les honoraires, le calendrier et les expérimentations éventuelles sont convenus avant le début; la réalisation technique fait l’objet d’un engagement distinct.