Cadrer un produit IA avant de choisir un modèle

Commencer par une décision, pas par une technologie

Un besoin comme « ajouter de l’IA au support » ne décrit ni un produit ni un résultat. Il faut le ramener à une décision observable : classer une demande, proposer une réponse, retrouver une procédure, choisir une retouche ou déclencher un suivi. Tant que cette décision reste floue, l’équipe optimise une démonstration au lieu d’un usage.

Le cadrage tient dans une phrase : pour quel utilisateur, dans quel contexte, quelle décision doit devenir plus rapide, plus fiable ou plus simple ? Cette phrase oblige à choisir. Elle fait aussi apparaître les cas où une règle déterministe, une meilleure recherche ou une interface plus claire suffit.

• Utilisateur précis et contexte d’action
• Décision ou tâche réellement améliorée
• Coût actuel : temps, erreur, attente ou perte de contrôle
• Moment où le système rend la main

Dessiner le chemin complet

Le modèle n’est qu’une étape. Dessinez le chemin du signal jusqu’à l’action : donnée entrante, règles, appel de modèle, contrôle, décision humaine éventuelle, action puis retour d’usage. Une sortie correcte qui arrive trop tard, sans contexte ou sans possibilité de correction reste un mauvais produit.

Cette carte révèle les dépendances cachées. Qui possède la donnée ? Que se passe-t-il si elle manque ? Quelle action est réversible ? Qui voit une exception ? Quel événement permet ensuite d’améliorer le système ? Les réponses déterminent davantage l’architecture que le choix entre deux modèles proches.

Écrire les lignes rouges avant le prompt

Un produit IA doit savoir ce qu’il ne peut pas décider. Les lignes rouges dépendent du domaine : ne pas altérer une source sans validation dans un outil d’image, ne pas transformer une suggestion en décision clinique, ne pas lancer une action commerciale quand les preuves sont insuffisantes.

Pour chaque sortie, définissez trois états : exécutable, à confirmer, impossible à déterminer. Le troisième état est une capacité du produit, pas un échec. Il évite de maquiller l’incertitude et donne à l’opérateur une voie claire pour reprendre la main.

Tester une boucle utile, pas une vision complète

Le premier livrable doit fermer une boucle de valeur, même étroite. Une entrée réelle, une transformation utile, une validation et une action. Les fonctions périphériques peuvent rester manuelles tant que l’équipe observe où se trouve réellement la friction.

Mesurez ce qui rapproche de la décision : temps jusqu’à une première sortie exploitable, fréquence des corrections, motifs de refus, part des cas non traités et capacité à revenir en arrière. Un volume de générations ou un nombre de tokens consommés ne dit rien de la valeur produite.