D1L’IA est-elle vraiment nécessaire ?
Ce que je décide
Le problème vient d’abord, puis la raison pour laquelle un modèle est le bon outil pour le traiter. Un modèle mérite sa place quand la tâche est trop variée pour être gérée par des règles, quand une mauvaise réponse peut être détectée ou fait peu de dégâts, et quand il fait bouger un résultat mesuré.
En pratique
Yexit : la première tranche met en production des questions relues, sans modèle. La génération viendra une fois que le parcours de sauvegarde aura fait ses preuves.
D2Que veut dire « bon », en chiffres ?
Ce que je décide
Un seuil de qualité minimal, convenu avant le développement avec l’ingénierie et les personnes qui utiliseront la fonctionnalité, et relevé de version en version. Un jeu d’évaluation le mesure : 30 à 50 entrées réelles avec la sortie attendue, annotées par des personnes qui connaissent le domaine. Les scores du modèle sont subordonnés à un résultat produit, et c’est ce résultat qui tranche. Si le seuil n’est jamais atteint, la fonctionnalité n’est pas mise en production.
En pratique
Mémoire de MSc : les évaluateurs ont été soumis à des tests d’identité et d’oracle avant que le moindre score soit jugé fiable.
D3Prototyper d’abord, avec des entrées réelles
Ce que je décide
Un prototype fonctionnel mis entre les mains d’utilisateurs avant que la spécification soit finalisée. Il reste un prototype tant que les exigences bougent encore, que la valeur n’est pas démontrée ou que les échecs sont fréquents. Il passe à l’ingénierie quand les utilisateurs demandent à s’en servir pour leur travail réel, que les échecs sont l’exception et que le succès est défini. La passation comprend le prototype, le jeu d’évaluation, les modes de défaillance connus et le prompt qui a fonctionné.
En pratique
Yexit : des prototypes avec leurs états d’erreur (échec de l’envoi, échec du téléversement, hors ligne, accès au micro refusé) et une passation qui indique ce qui est fonctionnel et ce qui est simulé.
D4Concevoir pour la mauvaise réponse
Ce que je décide
Ce que l’utilisateur voit quand le modèle se trompe, est incertain ou est bloqué. Les sorties de l’IA sont signalées comme telles et modifiables, les utilisateurs sont informés des erreurs auxquelles s’attendre, et les cas incertains se replient sur une option sûre. Les tests d’injection de prompt et de biais sont inscrits dans la spécification, pour qu’ils soient effectivement faits.
En pratique
Yexit : les brouillons du modèle ne sont que des candidats. Les questions partagées passent des contrôles automatiques et une relecture éditoriale. Les sujets personnalisés basculent sur une solution de repli quand trop peu de bonnes questions en sortent, et les suggestions personnalisées portent la mention Concept.
D5Tracer la frontière des données
Ce que je décide
Ce que le modèle peut recevoir, ce qu’il ne doit jamais recevoir, et un test qui le prouve. On tranche dès le départ si les données utilisateur peuvent servir à entraîner quoi que ce soit, et l’usage des données doit être de ceux que l’équipe accepterait de décrire en public. Avant que des données utilisateur entrent dans un outil d’IA, quel qu’il soit, ses conditions de confidentialité sont vérifiées.
En pratique
Yexit : le générateur de questions ne voit jamais les réponses. Le premier test d’acceptation vérifie qu’aucun contenu issu des réponses n’atteint un point de terminaison de questions ou d’inférence.
D6Chiffrer le coût avant la mise en production
Ce que je décide
Le coût par requête, par utilisateur et par tâche réussie, au volume prévu, dans le cadre du choix du modèle. Les marges de l’IA sont plus faibles que celles du logiciel classique, donc un plafond de dépenses est convenu avec la personne responsable du budget avant le lancement. Une fonctionnalité qui enchaîne plusieurs étapes de modèle perd en fiabilité à chaque étape, et chaque nouvelle tentative coûte de l’argent.
En pratique
Sprint tool : une page de planification pour les fonctionnalités d’IA, qui convertit le coût de fonctionnement et l’effort de maintenance en capacité de sprint restante, avec des calculs optionnels pour les agents.
D7Lancer à petite échelle, surveiller, revenir en arrière
Ce que je décide
Un déploiement progressif : d’abord dans l’ombre de la version actuelle, puis auprès d’un petit groupe, puis plus largement. Un échantillon hebdomadaire de sorties réelles, noté avec la grille d’évaluation, et une alerte quand une métrique franchit son seuil. Des versions de modèle figées. Les changements de prompt traités comme du code : versionnés, testés sur le jeu d’évaluation, avec un responsable désigné pour le retour arrière.
En pratique
Yexit : les sujets personnalisés sont cadrés comme un pilote derrière un feature flag. Le suivi en production n’a pas commencé, car le produit n’est pas encore lancé.