Un salarié a construit un outil avec l’IA : comment éviter qu’il devienne impossible à maintenir ?

Comment garder maintenable un outil construit avec l’IA par un salarié ?

Un outil construit avec l’IA par un salarié reste maintenable avec cinq habitudes, dès le départ. Un dépôt avec historique, une copie d’essai séparée de la production, des tests à chaque modification, des droits et des passerelles explicites, et des décisions datées. Inscrivez ces exigences dans la méthode opérationnelle qui accompagne l’outil. Elles font partie du travail demandé au salarié. Même lorsque la première version répond à un besoin très limité. Demandez des éléments consultables. Une assurance orale ne suffit pas pour vérifier que ces habitudes existent.

1. Conservez le code dans un dépôt avec historique. Demandez où se trouve la version utilisée. Vérifiez que le dépôt garde les modifications. L’entreprise doit pouvoir y accéder avec un compte qu’elle maîtrise.
2. Prévoyez une copie d’essai distincte. Faites identifier clairement l’environnement des essais et celui des utilisateurs au quotidien. Le salarié doit montrer où il vérifiera une modification avant son utilisation réelle.
3. Demandez des tests à chaque modification. Pour toute évolution proposée, faites préciser le comportement attendu et les vérifications prévues. Gardez leur résultat avec la modification concernée, y compris lorsqu’un contrôle échoue.
4. Rendez les droits et les passerelles explicites. Faites tenir une liste des accès accordés à l’outil et de ses connexions aux services externes. Chaque connexion doit avoir un usage déclaré et une personne responsable.
5. Consignez les décisions avec leur date. Demandez une note lorsqu’un choix engage la suite du travail. Elle doit préciser sa raison et les contraintes connues au moment du choix. Quelques lignes peuvent suffire.

Cinq points vérifiables pour encadrer les évolutions. Si l’un manque, ajoutez sa mise en place au travail prévu. Demandez un livrable précis : un accès au dépôt, par exemple, se vérifie en l’ouvrant.

Pourquoi le dixième agent casse-t-il ce que le premier avait réussi ?

Le dixième agent reçoit le code sans la raison des choix initiaux. Il peut alors casser ce qui fonctionnait. Le risque : supprimer une précaution en la prenant pour une erreur. Prenons un outil qui écarte les fiches sans adresse électronique. Ce filtre évite les relances impossibles à envoyer. Un agent doit retrouver les clients manquants dans le tableau. Il retire le filtre, et les relances échouent. Un autre agent rétablit le filtre pour corriger les envois. Les clients disparaissent à nouveau du tableau. La réparation tourne en boucle : personne ne lui a précisé que les deux usages ont des besoins différents.

Dans un essai randomisé auprès de 16 développeurs expérimentés travaillant sur 246 tâches réelles de leurs propres dépôts, l’usage d’outils d’IA allonge le temps de réalisation de 19 %, alors que les développeurs estiment après coup avoir été 20 % plus rapides.

Sur douze mois de données de dépôts réels, la part des lignes modifiées liées au refactoring passe de 25 % en 2021 à moins de 10 % en 2024, le code copié-collé est multiplié par quatre et dépasse pour la première fois le code déplacé.

Dans l’enquête 2025 auprès des développeurs, 84 % utilisent ou prévoient d’utiliser des outils d’IA (76 % l’année précédente), davantage se méfient de l’exactitude de ces outils (46 %) qu’ils ne s’y fient (33 %), et 66 % citent comme première frustration des solutions presque justes, mais pas tout à fait.

Comment organisons-nous la maintenance de notre propre système ?

Nous organisons notre maintenance autour de modules gelés sous certificat. Chaque modification suit un circuit planifié. Des décisions écrites et datées accompagnent ce travail. Un miroir de test permet les vérifications. Nous conservons un test pour chaque défaut corrigé. Le gel impose un arrêt. Un agent propose de simplifier du code pendant une autre intervention ? Cela ne justifie pas de retoucher au passage une partie déjà validée. Notre méthode opérationnelle fixe cette limite. Modifier un module gelé constitue une intervention à part entière. Il faut une raison explicite, puis une nouvelle vérification avant de remettre cette partie en service.

Le rapport DORA 2025 observe une relation positive entre adoption de l’IA et débit de livraison logicielle, mais une relation toujours négative entre adoption de l’IA et stabilité des livraisons ; l’IA ne répare pas une équipe, elle amplifie ce qui existe déjà.

Le certificat doit préciser le périmètre validé et les conditions de cette validation. La personne chargée de la prochaine intervention doit savoir sur quoi s’appuyer. Elle doit aussi savoir ce que sa modification oblige à vérifier de nouveau. Pour juger le dispositif, vérifiez si la validation correspond encore à la version utilisée. Un certificat attaché à une ancienne version ne suffit pas. Il n’établit pas que la version modifiée fonctionne dans les mêmes conditions.

Pour appliquer cette organisation à votre outil, demandez au responsable de préparer la prochaine intervention. Il doit désigner le module concerné et la décision qui autorise sa réouverture. Cela précède le travail de modification confié à un agent. Faites passer l’intervention par le miroir de test prévu dans le circuit de maintenance. Demandez ensuite que le défaut corrigé laisse un test dans le projet. Cette trace fait partie du travail livré. Au moment de valider, exigez une décision datée et un certificat correspondant à la version proposée. Faites préciser les vérifications qui permettent de refermer le module. Faites aussi préciser qui prend la responsabilité de le remettre en service.

Que se passe-t-il quand un fournisseur change ses règles ou ses accès ?

Un fournisseur change ses règles ou ses accès. La connexion peut alors cesser de fonctionner. Chaque passerelle doit avoir un responsable chargé de l’adapter aux nouvelles conditions du service. Prenons un outil qui consulte les commandes chez un fournisseur pour préparer un suivi client. Le fournisseur exige une nouvelle autorisation. La personne chargée de cette connexion doit pouvoir retrouver les données reçues et transmises par l’outil. Elle doit aussi retrouver les droits du compte utilisé pour cet échange. Consulter les commandes ne donne pas nécessairement le droit de les modifier. La fiche de la passerelle doit préciser cette limite. Inscrivez le nom du responsable de l’adaptation dans votre méthode opérationnelle. Indiquez qui, dans l’entreprise, peut autoriser un changement de droits. Si le fournisseur réclame un accès plus large, le salarié chargé de réparer la connexion doit savoir à qui soumettre la demande. Avant de l’accepter.

Que faut-il écrire pour qu’une autre personne puisse reprendre l’outil ?

Pour préparer la reprise, conservez l’historique des modifications de l’outil dans le dépôt. Reliez les changements importants à une décision datée qui explique leur raison. L’historique permet de retrouver les versions successives du code et leurs différences. Le texte de décision précise le besoin auquel répondait le choix. Il garde aussi les contraintes connues à ce moment-là. La personne qui reprend l’outil doit pouvoir partir d’une modification visible dans l’historique et retrouver son explication. Sans demander au salarié de reconstituer de mémoire une discussion ancienne.

Pour chaque choix qui engage la suite, demandez une note conservée avec le code. La date et le nom de la personne qui a décidé. Puis le problème rencontré et la raison de la solution retenue. Gardez aussi la piste écartée lorsqu’elle explique une limite encore présente dans l’outil. Précisez ce qui avait conduit à l’abandonner. Indiquez dans quelles circonstances elle pourrait redevenir pertinente pour la personne chargée de la reprise. Quelques lignes peuvent suffire. « Changement pour simplifier » laisse le lecteur deviner ce qui posait problème. Décrivez la difficulté concrète que le changement devait résoudre. Associez ensuite la note à la modification concernée. Son explication doit rester accessible depuis le dépôt.

Si une décision change, conservez son texte initial. Ajoutez une nouvelle note qui indique explicitement laquelle elle remplace. Précisez la raison du changement et sa date. La personne qui reprend le travail pourra distinguer une contrainte toujours valable d’un choix abandonné. Même en consultant une ancienne version pour comprendre le fonctionnement de l’outil à cette époque. Inscrivez une vérification de passation dans votre méthode opérationnelle. Demandez à la personne qui reprend l’outil de retrouver la raison d’une modification importante à partir du dépôt seul. Complétez ensuite la note avec les explications qu’elle a encore dû demander oralement.

Pourquoi essayer une modification sur une copie séparée de la production ?

Une copie séparée de la production permet de vérifier une modification sans interrompre le travail des utilisateurs. À une condition : cette copie ne doit ni modifier leurs données ni déclencher d’actions réelles. Prenons une évolution du calcul des remises dans un outil de devis. La personne chargée du changement l’installe sur une version d’essai. Elle utilise des devis fictifs dont elle connaît les montants attendus. Elle compare les résultats obtenus avec ceux attendus avant de proposer l’utilisation à l’équipe commerciale. La séparation doit être réelle. La copie utilise encore le fichier de commandes de l’entreprise ? Elle peut envoyer un devis à un client ? L’essai peut alors avoir des conséquences en production. Donnez à la copie ses propres données. Dirigez ses éventuels envois vers une boîte réservée aux essais. Même si son écran porte déjà la mention « test ».

Posez une condition de passage à la version utilisée par l’équipe. La personne qui connaît le travail concerné doit essayer le parcours modifié sur cette copie, jusqu’au document final. Elle doit confirmer que le résultat correspond au besoin demandé. Pour le calcul des remises, faites-lui reprendre un devis ordinaire puis un devis avec une remise exceptionnelle. Demandez-lui de vérifier le montant sur le document destiné au client. L’aperçu dans l’outil ne suffit pas. Si un écart reste inexpliqué, gardez la modification sur la copie d’essai. Poursuivez la vérification à cet endroit. Les utilisateurs continuent leur travail sur la version en service pendant cet examen.

Comment empêcher qu’un défaut corrigé revienne à la modification suivante ?

Pour détecter le retour d’un défaut corrigé, transformez le cas qui l’a révélé en test automatique. Rendez sa réussite obligatoire avant toute mise en production. Un défaut qui réapparaît après une modification s’appelle une régression. Prenons un exemple fictif : un outil de suivi crée une commande en double lorsqu’un salarié importe deux fois le même fichier. Après correction, le second import doit laisser la liste des commandes inchangée. Ce comportement attendu devient la règle à vérifier. Même si la prochaine modification concerne une autre fonction de l’outil.

1. Reproduisez le défaut dans un test. Préparez un fichier fictif contenant une commande. Faites exécuter deux imports successifs par le test. Demandez-lui de vérifier qu’une seule commande existe à la fin. Le résultat attendu doit correspondre au besoin du salarié.
2. Vérifiez que le test échoue avant la correction. Cette étape compte. Un test qui réussit alors que le doublon existe ne détecte pas le problème. Appliquez ensuite la correction et relancez exactement le même test. Il doit maintenant réussir, sans assouplir le résultat attendu.
3. Exécutez ce test à chaque modification. Configurez l’intégration continue pour cela. Elle lance automatiquement les vérifications à chaque nouvelle modification soumise dans le dépôt. Conservez le test du double import parmi ces vérifications. Même lorsque personne ne pense avoir touché au traitement des commandes.
4. Bloquez la mise en production en cas d’échec. Une personne peut ignorer une alerte seule. Configurez le circuit de livraison pour qu’un résultat en échec empêche la publication. Examinez ensuite la modification qui a fait revenir le doublon.

Un test réussi confirme uniquement le comportement qu’il vérifie. Si un autre défaut apparaît, ajoutez le cas correspondant. La méthode opérationnelle conserve ainsi une vérification exécutable de chaque correction. La prochaine personne qui modifiera l’outil doit pouvoir y accéder.

Quand faut-il organiser la maintenance de l’outil construit avec l’IA par votre salarié ?

Organisez la maintenance dès qu’une deuxième personne dépend de l’outil construit avec l’IA par votre salarié ou doit le modifier. À ce seuil, désignez un responsable. Il doit vérifier que les cinq habitudes existent avant d’engager la prochaine évolution. Même si l’outil donne satisfaction aujourd’hui. Faites de cette vérification une condition pour autoriser la suite.