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

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.

Parce que rien ne casse. Un test qui échoue signale une dette ; un système d'IA qui se dégrade continue de répondre.

À cela s'ajoute un facteur 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.

Le moment où quelqu'un dit : « on ne touche pas au prompt, ça marche ».

Cette phrase signale que le système est devenu incompréhensible pour ceux qui l'exploitent. Elle précède de quelques mois le moment où un changement de modèle deviendra impossible à absorber, et où il faudra tout reprendre.

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.

Un jeu de tests que plus personne n'alimente se périme en trois mois et donne une fausse assurance, ce qui est pire que son absence. C'est la dette la plus dangereuse des quatre.

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.

La règle qui l'évite est unique : toute réponse fausse signalée devient une ligne du jeu, le jour même. Sans analyse, sans réunion. La méthode figure dans construire un jeu de tests en une journée.

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. Le mécanisme est purement asymétrique.

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.

Au bout d'un an, le prompt contient des règles qui se contredisent, et le modèle arbitre comme il peut. Le nettoyage se fait par mesure, selon la démarche de réduire de moitié le contexte envoyé.

Une demi-journée par trimestre, avec un ordre du jour fixe, suffit à empêcher l'accumulation. C'est peu, et c'est ce qui manque.

Quatre points : rafraîchissement du corpus et vérification des documents modifiés ; rejeu du jeu de tests sur les modèles disponibles avec décision de bascule ; lecture d'un échantillon de questions réelles pour détecter la dérive ; relecture de 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.

La date de la dernière modification du jeu de tests : si elle remonte à plus de trois mois sur un système en usage, la dette est déjà installée. C'est l'indicateur le plus simple à relever et le plus prédictif.

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, 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.