Quand une équipe produit aborde sa première fonctionnalité IA, deux réflexes opposés se déclenchent, et les deux coûtent cher. Le premier consiste à tout réinventer, comme si vingt ans de pratique du cadrage ne s'appliquaient plus. Le second consiste à ne rien changer, à traiter ça comme n'importe quel développement — et à découvrir trois sprints plus tard qu'on ne sait pas dire si c'est terminé. La bonne posture est au milieu, et elle est assez précise pour se décrire.
Ce qui ne change pas
Je le dis en premier parce que c'est ce qu'on oublie le plus.
Le problème utilisateur. Il se formule pareil, il se vérifie pareil, il se documente pareil. Une fonctionnalité IA qui ne répond à aucun problème identifié est une fonctionnalité inutile qui coûte plus cher que les autres. La discipline habituelle s'applique : à qui, dans quel contexte, à quelle fréquence, avec quelle douleur.
Les critères de succès métier. Le taux d'usage, le temps passé sur la tâche, le taux d'abandon, le volume traité. Ce sont les mêmes indicateurs qu'avant, et ils restent les seuls qui décident si la fonctionnalité mérite d'exister. Une sortie techniquement excellente que personne n'utilise est un échec produit.
Le découpage. On livre petit, on mesure, on ajuste. Une fonctionnalité IA ne demande pas un projet de six mois avant la première mise en main. Le contraire, plutôt : comme le comportement se découvre à l'usage, il faut confronter tôt.
La conception d'interface. C'est du design classique, et c'est là que beaucoup de fonctionnalités IA échouent — pas sur le modèle, sur le fait que personne ne comprend quoi en faire.
Ce qui change vraiment
La sortie n'est pas déterministe. Même entrée, sortie différente. Cette seule propriété fait sauter trois habitudes : les tests d'acceptation binaires, les spécifications qui décrivent le comportement exact, et la recette qui vérifie que « ça fait bien X ». Il faut remplacer « ça doit produire ceci » par « ceci est acceptable, cela ne l'est pas ».
L'échec est normal et fréquent. Dans un développement classique, un cas qui rate est un bug qu'on corrige. Ici, un certain taux de sorties inutilisables fait partie du fonctionnement nominal. On ne le corrige pas, on le dimensionne — et on conçoit l'expérience autour.
La qualité n'est pas gratuite à mesurer. Vérifier qu'un calcul est juste, ça s'automatise. Vérifier qu'un résumé est bon, ça demande du jugement humain, donc du temps de gens compétents. C'est une ligne de coût récurrente, pas une tâche de fin de projet.
Le comportement bouge sans qu'on y touche. Le fournisseur met à jour son modèle, les données d'entrée évoluent. La maintenance change de nature : pas des correctifs, une surveillance.
Le cadre en cinq questions
Voici ce que je fais écrire avant d'engager quoi que ce soit. Une page, cinq réponses. Si une manque, on ne démarre pas.
1. Quelle décision ou quelle tâche cette sortie sert-elle ?
Pas « générer un résumé ». Qui lit ce résumé, pour décider quoi, et que faisait-il avant ? Si la réponse est floue, la fonctionnalité est une démonstration technique déguisée.
2. Qu'est-ce qu'une sortie acceptable ?
La question centrale, et la plus fuie. Elle se répond avec le métier, sur des cas réels, pas dans l'abstrait.
La méthode qui marche : prendre vingt à trente cas représentatifs, faire produire une sortie pour chacun, et faire trancher un expert métier — acceptable tel quel, oui ou non. Les désaccords entre relecteurs sont l'information la plus utile de l'exercice : ils révèlent que le critère n'était pas partagé, ce qui aurait explosé plus tard.
De là sort un seuil. Par exemple : on considère la fonctionnalité livrable si au moins tant de sorties sur vingt sont acceptables. Le chiffre dépend entièrement du métier et du coût de l'erreur, et il se décide avant, jamais après avoir vu les résultats.
3. Que se passe-t-il quand ça rate ?
Le repli fait partie de la fonctionnalité, pas des cas limites. Trois options à arbitrer explicitement : ne rien afficher, afficher avec une réserve visible, ou passer la main à un humain.
Une règle que j'applique : la fonctionnalité doit être utilisable si l'IA est indisponible. Si l'utilisateur est bloqué quand le service tombe, tu as créé une dépendance critique sur un composant que tu ne contrôles pas.
4. Comment l'utilisateur sait-il à quoi il a affaire ?
Est-ce qu'il voit que c'est généré ? Est-ce qu'il peut corriger, et sa correction sert-elle à quelque chose ? Est-ce qu'il peut remonter une sortie mauvaise en un geste ?
Ce dernier point est souvent traité comme un détail, alors qu'il est ta principale source de données de qualité une fois en production. Un simple pouce vers le bas, stocké avec le contexte de l'appel, vaut mieux qu'un dispositif d'évaluation sophistiqué qu'on ne mettra jamais en place.
5. Qui regarde, à quelle fréquence, et avec quel budget ?
Un nom, un rythme, un temps prévu. Relire un échantillon chaque mois, suivre les indicateurs, décider d'ajuster ou d'arrêter. Si personne n'est nommé, la fonctionnalité se dégradera sans que quiconque le sache.
Et budgète l'évaluation dans le chiffrage initial, comme une ligne à part. Elle ne disparaît pas après la mise en production : elle devient récurrente.
Le piège du démonstrateur convaincant
Un dernier point, parce qu'il fait dérailler beaucoup de cadrages. Le prototype construit en une journée impressionne toujours. Il est construit sur des cas choisis, il n'a pas de repli, il n'a pas d'évaluation, il n'a pas de surveillance.
L'écart entre ce prototype et la fonctionnalité livrable est de plusieurs fois le travail déjà fait, et il est constitué des cinq questions ci-dessus. Le dire tôt, devant les gens qui ont vu la démonstration, évite une négociation pénible au moment de la mise en production.
Le geste à faire avant ton prochain sprint
Prends la fonctionnalité IA qui est dans ton backlog. Réponds à la question 2 — qu'est-ce qu'une sortie acceptable — avec vingt cas réels et une personne du métier. Deux heures. Tu sauras, avant d'engager quoi que ce soit, si le sujet est mûr ou si tu allais construire quelque chose que personne ne pouvait valider.