La dette technique d’un système d’IA

La dette technique d’un système d’IA est l’accumulation de réglages, de consignes et de données qui ne sont plus maîtrisés, logée dans le prompt, le corpus, le jeu de tests et les paramètres plutôt que dans le code. Elle dégrade le système sans faire échouer aucun test logiciel.

La dette technique classique se lit dans le code : duplication, couplage, absence de tests. On sait la mesurer et on sait la rembourser.

Celle d’un système d’IA se loge ailleurs, et elle est invisible aux outils habituels. Le code peut être impeccable pendant que le système se dégrade.

Je recherche la dette d’un système d’IA dans les consignes accumulées, les documents sans autorité, les cas de test figés et les paramètres sans justification actuelle.

• Le prompt sédimenté. Trois pages d’instructions empilées au fil des correctifs, dont plus personne n’ose retirer une ligne parce que personne ne sait laquelle sert encore.
• Le corpus jamais élagué. On ajoute, on n’enlève jamais. Avec le temps, une part croissante des documents indexés n’a plus d’autorité, et rien ne le signale.
• Le jeu de tests figé. Constitué au lancement, jamais enrichi. Il mesure encore parfaitement un usage que plus personne n’a.
• Les seuils oubliés. Un nombre d’extraits, une température, une longueur maximale, réglés une fois au jugé et jamais rejugés depuis trois modèles.

Chacune des quatre formes de dette d’un système d’IA laisse un symptôme observable et se rembourse par un geste précis, à condition de savoir où regarder. Le tableau suivant sert de grille de diagnostic.

La dette d’un système d’IA s’accumule vite parce que rien ne casse : un test qui échoue signale une dette logicielle, alors qu’un système d’IA qui se dégrade continue de répondre. Deux mécanismes l’aggravent.

Le premier est l’asymétrie. Chaque incident produit une règle supplémentaire dans le prompt, et personne ne retire jamais rien, faute de pouvoir mesurer l’effet d’un retrait. Ajouter une règle est rassurant et sans risque apparent. La retirer suppose de démontrer qu’elle ne sert pas, ce qui exige une mesure. En l’absence de jeu de tests, la prudence conduit donc à ne retirer jamais.

L’accumulation peut produire des règles contradictoires, sans durée universelle avant leur apparition. Le nettoyage se fait par mesure, selon la démarche de réduire de moitié le contexte envoyé, et la rédaction initiale gagne à suivre les principes d’un prompt système qui tient six mois.

Le second est humain : la personne qui a construit le système sait quelles instructions du prompt sont vestigiales. Quand elle part, cette connaissance part avec elle, et le prompt devient un objet qu’on modifie en ajoutant, jamais en retirant. Une fiche du système tenue à jour limite cette perte.

Un jeu de tests que plus personne n’alimente donne une fausse assurance, ce qui est pire que son absence, et c’est la plus dangereuse des quatre formes de dette. Il se périme au rythme où l’usage réel évolue.

Un jeu périmé continue de passer au vert sur des cas qui ne représentent plus l’usage réel. L’équipe croit mesurer et ne mesure rien, ce qui autorise des changements dont personne ne voit les conséquences, notamment lors d’une migration de modèle.

Chaque réponse fausse signalée doit être analysée, puis transformée en cas de test avec une attente validée. Conserver l’erreur telle quelle sans examen risquerait d’introduire une référence fausse. La méthode figure dans construire un jeu de tests en une journée.

Deux signaux révèlent une dette déjà installée dans un système d’IA : la phrase « on ne touche pas au prompt, ça marche », et une date de dernière modification du jeu de tests trop ancienne. Le premier est qualitatif, le second se relève en une minute.

La phrase signale que le système est devenu incompréhensible pour ceux qui l’exploitent. Elle appelle une vérification de la capacité à tester et expliquer un changement, sans prédire un délai précis avant incident. C’est aussi pourquoi j’impose qu’un référent interne modifie le prompt et mesure l’effet pendant la mission : la capacité à toucher au système est ce qui empêche la dette de se figer.

La date de dernière modification du jeu de tests est l’indicateur le plus simple à relever. Sa logique est directe. Un système en usage produit des réponses insatisfaisantes, régulièrement, parce qu’aucun système n’est parfait. Si aucune de ces réponses n’a donné lieu à une nouvelle ligne dans le jeu de tests depuis le dernier rendez-vous trimestriel, c’est que personne ne les remonte, ou que personne ne les traite.

Dans les deux cas, l’équipe a cessé d’apprendre de son système. Les changements suivants se feront à l’aveugle, et la dégradation ne sera détectée que par la baisse d’usage, c’est-à-dire trop tard.

Je pose donc cette question en premier lors d’une reprise, avant même d’ouvrir le code : quand le jeu de tests a-t-il été modifié pour la dernière fois. La réponse situe immédiatement l’état du système, et elle oriente tout le diagnostic décrit dans reprendre un système d’IA construit par quelqu’un d’autre.

Une revue régulière du prompt, du corpus, des tests et des paramètres permet de repérer les décisions devenues obsolètes avant de modifier le système en production. Je recommande de prévoir ce rendez-vous dans l’organisation, avec un responsable et une trace des décisions.

Un rythme trimestriel peut être un point de départ personnel ; les incidents et changements importants demandent une revue sans attendre cette échéance. L’effort dépend de la taille du corpus et du système.

Une revue planifiée aide à contenir la dette d’un système d’IA lorsqu’elle traite réellement les documents, les tests, les consignes et les paramètres devenus obsolètes. Sa durée se dimensionne selon le périmètre et les anomalies à traiter.

L’ordre du jour tient en six points, toujours les mêmes :

1. Rafraîchir le corpus : vérifier les documents modifiés et retirer ce qui n’a plus d’autorité, puisque le corpus est le projet.
2. Enrichir le jeu de tests avec les cas remontés depuis le dernier rendez-vous.
3. Élaguer le prompt en retirant les règles une à une et en mesurant chaque retrait.
4. Rejouer le jeu de tests sur les modèles disponibles, avec décision de bascule ou non.
5. Rejuger les seuils : nombre d’extraits, température, longueurs maximales.
6. Lire un échantillon de questions réelles pour détecter la dérive d’usage, puis relire la fiche du système.

Ce rituel produit une trace datée des décisions, qui sert à la fois à la conformité et à la personne qui reprendra le système. Son contenu détaillé figure dans ce qui occupe l’équipe la deuxième année.

Les erreurs qui aggravent le plus la dette d’un système d’IA consistent à corriger chaque incident par une consigne, à indexer sans jamais retirer et à confier le système à une seule personne. Elles paraissent prudentes sur le moment.

• Répondre à chaque incident par une règle de plus dans le prompt, sans en retirer aucune.
• Considérer le corpus comme une archive à laquelle on ajoute, plutôt que comme une source qu’on entretient.
• Garder les réglages initiaux à chaque changement de modèle, au lieu de les rejuger.
• Laisser toute la connaissance du système à son auteur, sans fiche ni référent capable de le modifier.

Pour évaluer l’état de la dette d’un système existant, un audit IA applique la grille des quatre formes et commence par la date du jeu de tests.

Lectures complémentaires : ce qui occupe l’équipe la deuxième année. Ces liens complètent la navigation du site.

Le diagnostic de dette technique IA examine les changements, les incidents, la représentativité des tests et la capacité de l’équipe à expliquer les paramètres réellement utilisés.