Toutes les publications

Reprendre un système d'IA construit par quelqu'un d'autre

MéthodeDiagnosticProductionTutoriel2025-11-1810 min

Le réflexe est d'ouvrir le prompt. C'est la troisième chose à regarder, et c'est pour cela que les reprises durent trois fois trop longtemps.

Pourquoi l'ordre compte autant

Ouvrir le prompt en premier est le réflexe naturel et la principale cause de reprise interminable. Le prompt est visible, lisible, modifiable : il attire l'attention alors qu'il est rarement la cause.

Un système documentaire comporte cinq couches. Le corpus qu'on lui donne, la récupération qui sélectionne, le prompt qui cadre, le périmètre qui borne, et les coûts qui contraignent. Les problèmes remontent presque toujours des deux premières.

Modifier le prompt sans avoir vérifié les deux couches en amont produit un cycle familier : on corrige un cas, on en casse deux autres, on ajoute une règle, le prompt double de taille, et la cause initiale reste en place.

Ordre d'inspection d'un système hérité, du corpus vers les coûts
Le prompt vient en troisième position, jamais en première.

Étape un : le corpus, en une demi-journée

Trois questions sur le corpus expliquent la majorité des mauvaises réponses d'un système hérité. Elles se posent sans lire une ligne de code.

Combien de documents, et de quand datent-ils ? Un corpus indexé une fois il y a dix-huit mois répond sur des procédures abrogées, avec assurance et sans aucun signal.

Existe-t-il plusieurs versions d'un même document, et laquelle fait autorité ? C'est la question qui révèle le plus souvent la cause profonde. Si personne ne sait répondre, le système ne peut pas le savoir non plus.

Les droits d'accès sont-ils appliqués, et à quel moment ? S'ils sont appliqués après la recherche, ce n'est pas une protection.

Ces trois réponses situent le travail avant toute intervention technique, le principe posé dans le corpus est le projet.

Étape deux : la récupération, en dix questions

  • Prendre dix questions réelles ayant mal fonctionné et vérifier, pour chacune, si le bon document figurait dans les extraits fournis au modèle.
  • Si le document n'y était pas, le problème est dans la recherche ou le découpage, jamais dans le prompt.
  • Vérifier le comportement sur les références exactes, numéros d'article, codes. Voir recherche hybride.
  • Compter les extraits envoyés. Au-delà de huit, il y a probablement du bruit et un surcoût.

Étape trois : le prompt, enfin

Un prompt hérité contient presque toujours des règles ajoutées après incident, dont plus personne ne connaît la raison, et dont certaines se contredisent. C'est ce qu'on cherche à ce stade.

La méthode est simple : lire le prompt en entier, et pour chaque règle, se demander quel incident l'a produite. Les règles dont personne ne peut expliquer l'origine sont candidates au retrait, mesuré sur le jeu de tests.

Le cas le plus fréquent est la contradiction. Une règle demande de toujours citer la source, une autre ajoutée six mois plus tard demande d'être concis. Le modèle arbitre comme il peut, de façon instable.

Le second cas est la règle qui compense un défaut amont : « si tu ne trouves pas l'information, cherche dans les documents connexes ». Cette instruction masque un problème de récupération et produit des réponses fondées sur des documents non pertinents. Le cadre de réécriture figure dans écrire un prompt système qui tient six mois.

Étapes quatre et cinq : le périmètre et les coûts

Deux questions closent le diagnostic : que fait ce système quand il ne sait pas, et combien coûte-t-il par mois et par fonctionnalité. Elles sont presque toujours sans réponse.

Le comportement en cas de doute détermine la confiance des utilisateurs. Un système qui invente plutôt que de refuser produit des erreurs indétectables, et son abandon suit de quelques mois. Le principe est développé dans le refus de répondre est une fonctionnalité.

Le coût par fonctionnalité révèle les gaspillages. Sur les systèmes hérités que je reprends, il n'est presque jamais mesuré, et trois lignes expliquent en général plus de la moitié de la facture.

Ces deux questions se traitent après les trois premières, parce qu'elles supposent de savoir ce que le système fait réellement.

La règle qui raccourcit toute reprise

Ne modifier aucune ligne avant d'avoir construit le jeu de tests. Sans lui, chaque correction est un pari, et l'on ne saura jamais si la version d'aujourd'hui est meilleure que celle d'il y a un mois.

Ce qu'il faut livrer à la fin d'une reprise

Un jeu de tests, une note d'une page sur le système, et la liste datée des décisions prises : ces trois livrables évitent que la reprise suivante reparte de zéro. Ils coûtent une journée sur un chantier de plusieurs semaines.

Le jeu de tests est le plus important parce qu'il survit à l'équipe. Il permet à la personne suivante de modifier sans casser, ce qui est exactement ce qui manquait au départ.

La note d'une page décrit la finalité, les données, la décision servie et le dispositif de supervision. Elle sert à la conformité et, plus prosaïquement, à comprendre le système dans deux ans.

La liste des décisions, quel palier pour quelle tâche, quel seuil, quel comportement en cas de doute, à quelle date, est ce qui distingue un système entretenu d'un système accumulé. C'est la meilleure protection contre la dette décrite dans la dette technique d'un système d'IA.

Questions fréquentes

Par quoi commencer une reprise ?

Par le corpus : combien de documents, de quand datent-ils, quelle version fait autorité, et quand les droits d'accès sont-ils appliqués. Ces réponses expliquent la majorité des mauvaises réponses.

Pourquoi ne pas ouvrir le prompt en premier ?

Parce qu'il est rarement la cause. Le modifier sans avoir vérifié le corpus et la récupération produit un cycle où l'on corrige un cas en en cassant deux autres.

Comment diagnostiquer la récupération ?

En prenant dix questions réelles ayant mal fonctionné et en vérifiant, pour chacune, si le bon document figurait dans les extraits fournis. S'il n'y était pas, le problème est en amont du prompt.

Que livrer à la fin d'une reprise ?

Un jeu de tests, une note d'une page sur le système, et la liste datée des décisions prises. Ces trois livrables évitent que la reprise suivante reparte de zéro.