Dans la plupart des équipes, une fonctionnalité est « done » quand le code est mergé, les tests passent, et la recette métier est validée. Pour une fonctionnalité IA, cette définition laisse dehors à peu près tout ce qui décide de sa survie. Six semaines plus tard, personne ne sait si la qualité a bougé, ce qui se passe quand le fournisseur est en panne, ni combien coûte réellement l'usage. La fonctionnalité est en production et elle n'est pas finie.
La correction n'est pas un nouveau processus. C'est six lignes ajoutées à la definition of done existante.
1. Le jeu d'évaluation est passé, et le résultat est écrit
Pas « on a testé, c'était bon ». Le jeu de référence a été exécuté sur la version qui part, la grille a été appliquée, le score est consigné avec la date, la version du modèle et la version du prompt.
Ce qu'on cherche à obtenir ici, c'est un point de comparaison. Le jour où quelqu'un dira « je trouve que c'est moins bon qu'avant », il y aura un chiffre en face et pas une impression contre une autre.
Condition de sortie : le score atteint le seuil d'acceptation décidé au cadrage, et aucun cas critique n'échoue.
2. Le comportement de repli est implémenté, et testé
Le modèle sera indisponible. Il répondra hors format. Il dépassera le délai. Ce ne sont pas des hypothèses, ce sont des certitudes à l'échelle d'une année.
Ce que je vérifie :
- Que se passe-t-il à l'écran quand l'appel échoue ? Un message clair, et un chemin manuel qui reste praticable.
- Y a-t-il une reprise automatique, combien de tentatives, et un délai maximum au-delà duquel on abandonne proprement ?
- Le cas de la réponse mal formée est-il traité comme un échec, ou passe-t-il silencieusement en base ?
Le test correspondant existe : on simule la panne et on vérifie que le parcours tient. Une fonctionnalité IA dont le repli n'a jamais été exécuté n'a pas de repli, elle a une intention de repli.
3. Le coût par usage est mesuré, sur des données réelles
Pas une estimation faite au cadrage à partir d'un prix affiché. Une mesure : consommation observée sur les cas de recette, ramenée à l'unité métier — coût par dossier, par demande, par document traité.
Puis la projection au volume annuel réel, à côté du budget prévu. Cette ligne provoque parfois des conversations utiles avant la mise en production plutôt qu'à la première facture.
Ajoute la borne : un plafond de dépense avec alerte. Une boucle mal fermée ou un usage inattendu peut multiplier la consommation en une nuit.
4. Les garde-fous sont testés
Trois vérifications, avec des cas de test qui restent dans la suite de tests :
- Le système refuse correctement ce qui est hors périmètre, et le refus est lisible pour l'utilisateur.
- Aucune donnée sensible ne ressort là où elle ne doit pas. Sur ce point je m'en tiens à des principes généraux et aux obligations propres à chaque secteur ; ce n'est pas un avis juridique, et les cas particuliers se traitent avec un conseil qualifié.
- Les tentatives d'injection d'instruction dans les contenus lus par le système ne modifient pas son comportement.
Ces tests sont rejoués à chaque changement de prompt système, au même titre que les tests de non-régression classiques.
5. La documentation d'exploitation existe
Pas une documentation d'architecture. Une page destinée à celui qui recevra l'appel un mardi soir. Elle contient :
- ce que fait la fonctionnalité, en trois phrases, dans les mots du métier ;
- quel modèle, quelle version, où sont les prompts dans le dépôt ;
- comment on la désactive — l'interrupteur, et ce que voient les utilisateurs une fois coupée ;
- les trois pannes probables et le premier geste pour chacune ;
- où lire les journaux, où voir la consommation ;
- comment rejouer le jeu d'évaluation.
Si tu ne devais garder qu'une ligne, garde l'interrupteur. Une fonctionnalité IA qu'on ne peut pas couper en cinq minutes est un risque d'exploitation, quelle que soit sa qualité.
6. Un propriétaire est désigné, avec un rendez-vous
Un nom. Pas une équipe, pas un comité. La personne qui, dans trois mois, répondra à la question « est-ce que ça marche toujours ».
Son engagement est concret : la revue par échantillon a une place dans son agenda, elle reçoit les alertes de coût et d'erreur, et une date de première réévaluation est posée — je recommande soixante à quatre-vingt-dix jours après la mise en production.
Sans ce point, les cinq précédents s'érodent. Le jeu d'évaluation existe et personne ne le rejoue. Les alertes partent vers une boîte que personne ne lit. C'est la ligne la plus facile à cocher et la plus souvent bâclée.
Ce que cette DoD coûte, et ce qu'elle évite
Comptons honnêtement : elle ajoute du travail à chaque livraison. Une à deux journées sur une première fonctionnalité, nettement moins ensuite, parce que le jeu d'évaluation, le repli et la trame de documentation se réutilisent.
Ce qu'elle évite, c'est la situation que je rencontre le plus souvent en audit : une fonctionnalité IA en production depuis un an, que plus personne ne sait évaluer, dont le coût réel n'est pas connu, et que l'équipe n'ose plus toucher parce qu'elle ignore ce qui casserait. À ce stade, la seule option raisonnable est de la refaire.
Ce que tu peux faire dès la prochaine livraison
Ne déploie pas tout d'un coup. Ajoute deux lignes à ta DoD actuelle : le comportement de repli testé, et un nom de propriétaire avec une date de réévaluation. Ce sont les deux qui rapportent le plus vite. Le reste s'ajoutera à la fonctionnalité suivante.