Après une modification par l’IA, tester la version destinée aux clients

Imaginons une équipe qui utilise une IA pour ajouter une fonction de téléchargement à son logiciel de suivi des interventions. Une gestionnaire veut récupérer la liste des interventions terminées dans le mois pour préparer son rapport dans Excel. L’équipe choisit le format CSV, qui organise les données en lignes et en colonnes.

La première version réussit les tests automatisés. L’IA corrige ensuite le traitement des dates. Même mineure en apparence, cette modification peut changer la liste des interventions incluses dans le fichier. Si l’équipe met cette nouvelle version en production en s’appuyant sur les résultats précédents, elle approuve un comportement qu’elle n’a pas encore vérifié.

Ce problème peut survenir avec un seul outil d’IA ou avec plusieurs agents qui se partagent le travail. Pour l’éviter, il faut conserver le lien entre la demande, la version du code et les résultats des tests.

Conserver un dossier clair pour chaque modification

La personne qui reprend le travail doit pouvoir retrouver la fonctionnalité demandée, la version proposée et les vérifications effectuées. Elle doit aussi savoir quelles questions restent à régler. Sans ces renseignements, un message disant simplement « terminé » ne permet pas de savoir ce qui a réellement été fait.

L’équipe technique utilise un identifiant de version, par exemple celui d’un commit Git, pour reconnaître les fichiers qui ont été examinés. Un commit correspond à un état enregistré du code. Si les fichiers changent après les tests, il faut identifier ce nouvel état et relancer les vérifications concernées.

La demande peut elle aussi évoluer. Si la gestionnaire décide que les interventions rouvertes doivent figurer dans le rapport, les exemples de résultats attendus et les tests doivent refléter ce choix. Consigner la décision et sa date évite que deux personnes vérifient le logiciel selon des exigences différentes.

Suivre la modification jusqu’à son utilisation par les clients

Étape	Travail dans cet exemple	Condition pour poursuivre
Clarifier	Définir les interventions et les colonnes du rapport	Le responsable du produit approuve les règles
Développer	Ajouter le téléchargement dans une copie de travail	Une version identifiable du code est prête à être examinée
Vérifier	Examiner le fichier et tenter d’accéder à des dossiers interdits	Les résultats portent sur cette version précise
Approuver	Examiner le résultat et les questions en suspens	Une personne habilitée approuve la version, ou celle-ci satisfait aux règles d’approbation établies
Mettre en production	Déployer la version approuvée	Le système consigne la version installée
Surveiller	Vérifier que les utilisateurs reçoivent le fichier attendu	L’équipe peut détecter un problème et désactiver la fonctionnalité

Certaines étapes peuvent être automatisées. La distinction proposée par Anthropic entre processus et agents aide à concevoir ce fonctionnement : l’IA peut choisir comment effectuer son travail, tandis que les conditions de passage d’une étape à l’autre sont définies à l’avance.

Confier chaque problème à la personne qui peut le résoudre

Si l’IA ne sait pas si une intervention annulée doit figurer dans le rapport, une décision sur le produit est nécessaire. Relancer l’IA ne répond pas à la question. Le travail peut être suspendu en attendant la réponse, en conservant la question précise et les fichiers déjà préparés.

Si un test montre qu’un compte peut télécharger les dossiers d’une autre entreprise, il faut corriger le code. La règle qui sépare les données des clients reste applicable. Supprimer le test qui a détecté l’erreur ne résout pas le problème.

Si un service cesse de répondre pendant la création du fichier, examinez ce qui s’est passé avant de recommencer. L’opération peut avoir abouti sans que sa réponse soit parvenue à l’application. Le mécanisme de nouvelle tentative doit éviter d’exécuter plusieurs fois la même opération.

Protéger la décision de mise en production

L’IA qui modifie l’application ne doit pas pouvoir assouplir elle-même les règles de mise en production. L’équipe doit protéger les vérifications obligatoires et les droits de déploiement. Deux agents qui travaillent dans des dossiers distincts peuvent disposer des mêmes droits; les outils doivent donc faire respecter la séparation prévue.

Les environnements de déploiement de GitHub offrent, par exemple, des mécanismes de protection avant la mise en production. Les fonctions disponibles dépendent du dépôt et du forfait. Quelle que soit la plateforme, demandez à l’équipe de montrer comment elle bloque une version non approuvée.

Repérer ce qui retarde réellement la livraison

Mesurez le temps d’attente, d’examen et de correction en plus du temps de programmation. L’IA peut écrire le code rapidement, alors que la modification attend ensuite plusieurs jours qu’une personne prenne une décision. Rendre ce délai visible aide à choisir l’amélioration utile.

Pour un premier essai, choisissez une fonctionnalité bien délimitée et suivez-la à chaque étape. Vérifiez aussi, dans l’environnement de test, qu’une version volontairement incorrecte est refusée. La démarche rejoint l’analyse d’une demande d’automatisation : suivre le travail jusqu’à l’obtention d’un résultat utilisable.

Le premier article aide à répartir les responsabilités. Le suivant montre comment rédiger une demande que le développeur, l’IA et la personne chargée de la vérification comprendront de la même façon.