Ce que vous saurez faire
À la fin de cette leçon, vous saurez expliquer pourquoi un cycle de delivery classique ne suffit pas pour un produit IA, et quelles questions ajouter à votre planification.
Une sortie qui varie
Dans un produit traditionnel, une même entrée produit en principe la même sortie : un test réussi hier reste réussi demain tant que le code ne change pas. Avec un modèle génératif, la sortie est incertaine : deux appels identiques peuvent produire deux textes différents, et un changement de formulation dans une consigne peut déplacer le comportement de façon inattendue. Le modèle, la consigne (prompt), les documents fournis en contexte et les paramètres sont autant de leviers qui influencent le résultat sans qu'une ligne de code applicatif ne change.
Quatre conséquences pour le delivery
- La qualité se mesure, elle ne se constate pas. On parle de taux de réussite sur un jeu de cas, pas de « ça marche ».
- L'effort est moins prévisible. Passer d'une démonstration convaincante à un comportement fiable peut prendre bien plus de temps que prévu, et on le découvre tard si on ne mesure pas tôt.
- Le produit évolue après la livraison. Les usages réels, les données et les modèles sous-jacents changent : livrer n'est pas la fin du travail.
- Le coût et la latence dépendent du comportement. Une consigne plus longue ou une architecture à plusieurs appels change la facture et le délai de réponse.
Ce que cela change dans votre planification
Ajoutez systématiquement trois questions à vos réunions de cadrage : comment saura-t-on que c'est assez bon ? Que se passe-t-il quand c'est faux ? Comment reviendra-t-on en arrière ? Les autres modules détaillent la stratégie (M8) et l'évaluation (M17) ; ici, on s'intéresse à l'organisation du travail qui permet de livrer sereinement.
Pour réfléchir
Pensez à une fonctionnalité IA que vous avez vue en démonstration. Quelle partie de sa fiabilité reposait sur des exemples choisis à l'avance ? Qu'auriez-vous voulu mesurer avant de promettre une date ?