J'ai livré une fonctionnalité IA le vendredi. Le lundi, c'était un risque juridique.

Il y a deux vendredis, j’ai livré une fonctionnalité dont j’étais fier. Un petit assistant propulsé par un LLM qui aidait les utilisateurs à rédiger les réponses à des questionnaires de sécurité à partir des réponses précédentes de leur entreprise. C’était astucieux. Ça marchait bien en test. Les clients aimaient la démo.

Le lundi matin, j’avais trois problèmes :

1. L’assistant avait halluciné une certification SOC 2 que le client n’avait pas, et le client avait envoyé cette réponse à un prospect sans la vérifier.
2. L’évaluation confidentielle d’un fournisseur appartenant à un second client avait fuité dans les suggestions d’un autre client, via un bug de récupération que j’avais raté.
3. Le coût était 4 fois supérieur à ma projection, parce que l’assistant était invoqué à chaque frappe au clavier plutôt qu’à la soumission.

Aucun de ces modes de défaillance n’était inédit. Chacun d’eux était quelque chose que je connaissais en théorie et que j’avais ignoré en pratique parce que j’allais vite et que la démo était belle.

Les quatre garde-fous

Après deux semaines de nettoyage, d’e-mails d’excuses et de chirurgie architecturale, j’ai maintenant quatre règles sans lesquelles je ne livrerai pas une fonctionnalité LLM :

1. Des marqueurs de confiance sur les sorties

Chaque morceau de texte généré reçoit un indicateur visuel du degré de confiance qu’on peut lui accorder. Pas un score de probabilité, les utilisateurs ne savent pas quoi faire d’un « 87 % de confiance ». Un simple feu tricolore : ceci provient de vos propres données, ceci a été inféré, ceci est la meilleure supposition du modèle. Laissez l’humain décider.

2. L’isolation de la récupération

La récupération des données par tenant n’est pas qu’une affaire de requête en base. C’est une affaire de prompt. Si des documents du Client A peuvent apparaître dans la fenêtre de contexte du Client B, vous avez une fuite de données, même si la requête en base était correctement cloisonnée. La couche de récupération a besoin de son propre contrôle d’accès, testé indépendamment.

3. Des disjoncteurs de coût

Fixez un plafond de coût par utilisateur et par heure sur les appels à l’API LLM. Quand il saute, dégradez proprement, affichez des résultats en cache, désactivez la fonctionnalité, remontez un message. Ne laissez pas une boucle de rétroaction entre un frontend bavard et une API coûteuse transformer votre week-end en incident.

4. Un environnement de staging qui vous ment moins

Mon environnement de staging avait dix documents de test. La production en avait dix mille. Le comportement de récupération était complètement différent à l’échelle, plus de bruit, plus d’ambiguïté, plus d’occasions pour le modèle de confondre deux documents qui se ressemblent. Testez avec des données à l’échelle de la production, ou acceptez que vous testez un système différent.

La méta-leçon

Le vrai échec n’était pas technique. Il était culturel. J’ai livré un vendredi parce que je voulais le week-end pour « voir comment ça se passe ». Ce n’est pas une stratégie de déploiement. C’est un espoir.

Les fonctionnalités LLM ne sont pas des fonctionnalités au sens traditionnel. Ce sont des systèmes au comportement probabiliste, et leurs modes de défaillance ne sont pas les mêmes que ceux d’un code déterministe. Elles ont besoin de leur propre discipline de release, plus lente, plus instrumentée, avec plus de points de contrôle humains, pas moins.

Je pense toujours que cette fonctionnalité est une bonne idée. Je ne la livrerai simplement plus un vendredi.