DECISION TOOLKIT · JALONS DE DELIVERY
Faire mériter à chaque transition la suivante
Les neuf phases ne sont pas une checklist. Ce sont des obligations de preuve : chaque transition réduit une incertitude différente et protège l’investissement suivant.
Pas de preuve, pas de transition. Rouvrir un jalon est un signe d’apprentissage, pas un échec.
La plupart des autopsies de projets IA se trompent de coupable. Le rapport final incrimine le modèle : pas assez précis, pas assez fiable, « pas prêt pour notre métier ». En mission, nous observons presque toujours autre chose. Le modèle fonctionnait. Ce qui manquait, c’est une phase entière du projet : personne n’avait mesuré le workflow avant de le modifier, personne n’avait défini ce qui justifierait un arrêt, personne n’avait construit d’environnement d’évaluation avant d’exposer le système à de vrais utilisateurs.
Quand un projet IA échoue, cherchez la phase sautée avant de chercher le modèle fautif. Vous trouverez presque toujours la phase en premier.
Le problème n’est pas un manque de méthode en général — les organisations savent livrer des projets. C’est que l’IA déplace le risque vers des endroits inhabituels : la qualité est probabiliste, la preuve exige une baseline, les permissions deviennent une question d’architecture et la valeur ne survit pas sans gouvernance. D’où ce framework, issu de nos missions : l’anatomie complète d’un projet IA d’entreprise, en neuf phases.
Le framework en un coup d’œil
Un projet IA de bout en bout traverse neuf phases. Trois relèvent de la décision : l’intention, le diagnostic, le portefeuille. Trois relèvent de la construction : l’architecture, les fondations, le pilote. Trois relèvent de la valeur : la preuve, l’industrialisation, la valeur en continu. Chaque phase produit des livrables identifiables, expose un piège récurrent et se termine par un critère de sortie vérifiable. Tant que ce critère n’est pas rempli, passer à la suite ne supprime pas le travail : il le déplace plus loin, là où il coûte plus cher.
Le séquencement n’interdit pas d’itérer — un pilote peut renvoyer vers l’architecture, une preuve peut rouvrir le portefeuille. Mais les décisions, elles, sont ordonnées : on ne choisit pas un pattern technique avant d’avoir choisi un problème, et on n’étend pas un système avant d’avoir compté ses erreurs.
Le framework vaut pour un assistant documentaire comme pour un agent qui touche à la production : seul le poids relatif des phases change. Un cas à faible risque traverse les neuf phases en quelques semaines, avec des livrables légers ; un cas qui influence des décisions clients passe plus de temps en architecture, en fondations et en pilote. Sauter une phase n’est jamais un gain de temps : c’est un transfert de dette vers la production.
Phase 1 — La décision d’intention
Tout projet commence par une intention ; peu commencent par une décision. La phase 1 transforme « il nous faut de l’IA » en un choix explicite : quel problème, porté par quel sponsor, avec quel critère d’abandon. Ce dernier point est le livrable le plus important — et le plus rarement produit. Décider avant d’investir ce qui justifierait un arrêt coûte une heure de lucidité ; le décider après coûte une négociation politique.
Livrables. Une note d’intention d’une page : le problème formulé comme un résultat de workflow à changer, un sponsor nommé avec du temps réellement réservé, le budget de la phase de preuve et le critère d’abandon écrit.
Le piège classique. Le projet miroir : on lance parce qu’un concurrent a annoncé, sans problème propriétaire. Le sponsor est un nom sur une slide, pas une personne qui arbitrera quand il faudra trancher.
Critère de sortie. Vous pouvez passer à la phase suivante quand le sponsor énonce sans notes le résultat à changer et les conditions d’arrêt — et que les deux figurent dans un document qu’il a signé.
Phase 2 — Le diagnostic et la baseline
On ne peut pas améliorer un workflow qu’on n’a pas mesuré ; on peut seulement le changer. La phase 2 documente le workflow réel, pas le processus officiel : qui fait quoi, où le temps se perd, où les reprises se concentrent, quelles données circulent et sous quelles contraintes légales. C’est aussi le moment de figer la baseline qui rendra toute preuve ultérieure possible.
Livrables. Une cartographie du workflow tel qu’il est pratiqué ; des baselines chiffrées — temps de cycle, taux de reprise, taux d’exception, coût unitaire, variation de qualité ; un inventaire des données et systèmes touchés, avec leurs propriétaires.
Le piège classique. Mesurer après coup. Sans baseline, l’équipe devra prouver la valeur du pilote contre des souvenirs — et les souvenirs perdent toujours face au scepticisme du directeur financier. Variante fréquente : documenter le processus théorique du manuel qualité, que personne ne suit.
Critère de sortie. Vous pouvez avancer quand vous savez ce que le workflow coûte aujourd’hui, chiffres à l’appui, et que la personne qui le fait tourner reconnaît ces chiffres comme les siens.
Phase 3 — Le portefeuille et le premier cas
Même quand le mandat porte sur un seul cas d’usage, il faut le choisir contre des alternatives. La phase 3 construit un portefeuille de candidats et les évalue sur deux axes : le potentiel — matérialité économique, impact utilisateur, pertinence stratégique — et l’exécutabilité — accès aux données, complexité d’intégration, contrôles requis, faisabilité de l’évaluation. Le premier cas n’est pas celui qui promet le plus : c’est celui qui combine une valeur significative et le chemin le plus court vers une preuve fiable.
Livrables. Un portefeuille scoré potentiel × exécutabilité ; un premier cas choisi et documenté ; la liste des cas écartés avec la raison de leur report — elle évitera de rejouer le même débat chaque trimestre.
Le piège classique. Choisir le cas le plus spectaculaire : souvent face au client, souvent à haut risque, presque toujours le plus lent à prouver. Un premier échec visible coûte plus de crédibilité que trois succès discrets n’en rapportent.
Critère de sortie. Vous pouvez avancer quand le sponsor, le responsable du workflow et l’équipe technique défendent le même premier cas — pour les mêmes raisons.
Phase 4 — L’architecture et les frontières
Avant de construire, il faut tracer les frontières : quelles données entrent, quelles permissions s’appliquent, quel pattern technique porte le cas, et ce qui reste réversible. Sur le choix du pattern, notre règle rejoint les travaux d’ingénierie publiés par Anthropic sur la construction d’agents : commencer par le pattern le plus simple qui suffit — un appel outillé, une chaîne de prompts, un routage — et ne monter vers l’agentique que si le cas l’exige démontrablement. Côté intégration, des standards ouverts comme le Model Context Protocol réduisent le couplage aux fournisseurs et préparent la réversibilité.
Livrables. Un schéma des flux de données avec propriétaires ; un modèle de permissions où le système hérite des droits de l’utilisateur — jamais plus ; un choix de pattern justifié par écrit ; une analyse de réversibilité : ce que coûterait un changement de modèle ou de fournisseur.
Le piège classique. La sur-architecture : construire un agent autonome là où une chaîne de prompts suffisait, puis passer des mois à déboguer une autonomie dont personne n’avait besoin. Le piège inverse existe aussi : ignorer les permissions et découvrir en pilote que l’assistant expose des documents que l’utilisateur n’aurait jamais dû voir.
Critère de sortie. Vous pouvez avancer quand chaque donnée qui entre et sort du système a un chemin documenté, un propriétaire et une frontière de permission vérifiable.
Phase 5 — Les fondations
La phase 5 construit ce qui ne se voit pas dans une démo : des identités et des accès provisionnés proprement, des connecteurs de données fiables, des contrôles opérationnels et, surtout, l’environnement d’évaluation. C’est lui qui distingue un projet pilotable d’un projet à l’aveugle : un jeu de cas réels, représentatifs et volontairement gênants, rejouable à chaque modification. Le cadre de gestion des risques IA du NIST dit la même chose à sa manière : on ne gouverne que ce qu’on sait cartographier et mesurer.
Livrables. Des comptes de service à périmètre minimal ; des accès aux données opérationnels et journalisés ; un jeu d’évaluation construit sur des cas réels, y compris les cas limites ; les contrôles de base — journalisation, seuils d’alerte, procédure d’incident.
Le piège classique. Sauter l’environnement d’évaluation pour « aller plus vite au pilote ». L’équipe modifie ensuite les prompts au jugé, sans pouvoir distinguer une amélioration d’une régression, et le pilote devient une suite d’impressions contradictoires.
Critère de sortie. Vous pouvez avancer quand vous pouvez rejouer votre jeu d’évaluation et obtenir un score reproductible — avant qu’un seul utilisateur réel n’ait touché le système.
Phase 6 — Le pilote supervisé
Le pilote ne teste pas la technologie : il teste le workflow modifié, ses contrôles et ses humains. La phase 6 expose le système à un périmètre restreint et nommé, avec une validation humaine systématique au départ, puis échantillonnée à mesure que la confiance se construit sur des faits. Chaque erreur est typée : gravité, cause, détectabilité. C’est cette comptabilité des erreurs — pas l’enthousiasme des premiers utilisateurs — qui alimentera la décision de la phase 7. La supervision n’est pas une défiance envers le système : c’est l’instrument qui permettra, preuves en main, de la lever progressivement.
Livrables. Un périmètre écrit : utilisateurs nommés, cas couverts, cas explicitement exclus ; un circuit de validation humaine avec règles d’échantillonnage ; un registre d’erreurs typées ; des seuils de qualité fixés avant le lancement, pas après.
Le piège classique. Le pilote-démo : trois utilisateurs enthousiastes, aucun registre d’erreurs, et une décision d’extension fondée sur des anecdotes. Les erreurs qu’on ne compte pas pendant le pilote se comptent plus tard en incidents.
Critère de sortie. Vous pouvez avancer quand vous disposez d’un taux d’erreur mesuré par type de cas, comparé à la baseline humaine de la phase 2 — pas d’un sentiment général.
Phase 7 — La preuve et la décision d’extension
La phase 7 est une salle de décision, pas une célébration. Trois issues sont légitimes : scale — les seuils sont atteints, on étend ; adapt — la valeur existe mais ailleurs ou autrement, on reconfigure ; stop — les preuves manquent, on arrête et on capitalise les apprentissages. Un arrêt décidé sur preuves est un succès de gouvernance ; une extension par inertie est un échec différé. Les ordres de grandeur restent des fourchettes — un temps de traitement réduit de 30 à 50 % sur les cas standards, par exemple — et c’est votre baseline de phase 2 qui transforme une fourchette en fait.
Livrables. Un dossier de preuve : delta contre baseline, coûts complets — construction, exploitation, supervision —, incidents et leur résolution, adoption réelle ; une décision écrite — scale, adapt ou stop — signée par le sponsor.
Le piège classique. L’extension par inertie : « le pilote s’est bien passé », donc on étend, sans comparer les résultats aux seuils — souvent parce qu’aucun seuil n’avait été fixé en phase 6. Le stop n’a jamais été une option réelle, seulement une ligne sur une slide.
Critère de sortie. Vous pouvez avancer quand la décision est prise sur chiffres, signée, et que l’option stop était réellement sur la table.
Phase 8 — L’industrialisation
Mettre en production n’est pas la fin du projet : c’est le début des opérations. La phase 8 transforme un pilote qui marche en un service qui tient : observabilité — traces, coût par requête, dérive de qualité —, modèle d’exploitation clair — qui répond quand ça casse, avec quels engagements —, pilotage des coûts, et formation des équipes au nouveau workflow, pas seulement à l’outil. C’est aussi ici que se joue la durabilité économique du système : un coût par requête accepté en pilote peut devenir indéfendable à l’échelle si personne ne le surveille.
Livrables. Des tableaux de bord d’observabilité en production ; un runbook d’exploitation avec un propriétaire nommé ; des budgets et des alertes de coûts ; un plan de formation ancré dans le workflow ; la revue de sécurité de mise en production.
Le piège classique. Le transfert fantôme : l’équipe projet passe au sujet suivant, personne n’est d’astreinte, les coûts dérivent silencieusement et la qualité se dégrade sans témoin. Le système meurt en production — lentement, et sans certificat de décès.
Critère de sortie. Vous pouvez avancer quand le système a un propriétaire opérationnel nommé, un budget suivi et une qualité mesurée en continu — pas seulement les jours d’incident.
Phase 9 — La valeur en continu
La dernière phase n’a pas de fin : c’est le régime permanent. Les baselines redeviennent vivantes — re-mesurées à intervalle régulier, parce que le workflow, les volumes et les modèles changent. Une gouvernance mensuelle courte examine valeur, coûts, risques et arbitrages. Et les gains démontrés financent les cas suivants du portefeuille : c’est le réinvestissement, pas l’enthousiasme, qui transforme un premier projet en programme.
Livrables. Des baselines re-mesurées et datées ; une revue mensuelle à ordre du jour fixe — valeur, coûts, incidents, risques, décisions ; une logique de réinvestissement reliant les gains prouvés aux prochains cas du portefeuille.
Le piège classique. Déclarer victoire à la mise en production et cesser de mesurer. Six mois plus tard, personne ne sait si le système crée encore de la valeur — ni s’il en a jamais créé. Le budget suivant se négocie alors sur la foi, face à un directeur financier qui n’en a pas.
Critère de sortie. Cette phase ne se quitte pas ; elle se tient. Vous êtes au bon régime quand chaque revue mensuelle produit au moins une décision : étendre, ajuster, arrêter ou réinvestir.
Les neuf critères de sortie en un tableau
| Phase | Vous pouvez passer à la suite quand… |
|---|---|
| 1. Décision d’intention | Le sponsor énonce sans notes le résultat à changer et le critère d’abandon. |
| 2. Diagnostic & baseline | Le coût actuel du workflow est chiffré et validé par son responsable. |
| 3. Portefeuille & premier cas | Sponsor, métier et technique défendent le même cas, pour les mêmes raisons. |
| 4. Architecture & frontières | Chaque donnée a un chemin documenté, un propriétaire, une permission vérifiable. |
| 5. Fondations | Le jeu d’évaluation produit un score reproductible avant tout utilisateur réel. |
| 6. Pilote supervisé | Le taux d’erreur est mesuré par type de cas et comparé à la baseline humaine. |
| 7. Preuve & extension | La décision scale, adapt ou stop est prise sur chiffres et signée. |
| 8. Industrialisation | Propriétaire opérationnel nommé, budget suivi, qualité mesurée en continu. |
| 9. Valeur en continu | Chaque revue mensuelle produit au moins une décision. |
Du framework au plan d’exécution
Neuf phases tiennent dans un article ; leur exécution tient dans un plan. Pour montrer concrètement ce que produit chaque phase, nous avons anonymisé un plan d’implémentation complet d’environ cinquante pages, issu d’une mission réelle : il déroule les neuf phases livrable par livrable, de la note d’intention de la phase 1 aux revues mensuelles de la phase 9, avec les modèles de documents et les seuils utilisés.
Deux règles résument l’usage du framework. Ne sautez aucune phase : chacune existe parce que son absence a un coût documenté. Et n’en faites pas une bureaucratie : sur un cas simple, une phase peut tenir en une réunion et deux pages. Ce qui compte n’est pas la durée d’une phase, c’est que son critère de sortie soit rempli.
Par où commencer lundi
- Nommez le sponsor et faites-lui écrire le critère d’abandon — avant toute conversation sur les outils.
- Choisissez un workflow et mesurez-le pendant une à deux semaines : temps de cycle, reprises, exceptions, coût unitaire.
- Scorez trois à cinq cas candidats sur potentiel × exécutabilité, et n’en retenez qu’un.
- Dessinez sur une page les flux de données et le modèle de permissions du cas retenu.
- Constituez un jeu d’évaluation à partir de cas réels — y compris les cas gênants — avant d’écrire le moindre prompt.
- Fixez par écrit les seuils de qualité du pilote et la date de la décision scale, adapt ou stop.
- Réservez dès maintenant la revue mensuelle dans les agendas : une gouvernance qui n’est pas planifiée n’existe pas.
La différence entre un projet IA qui prouve et un projet IA qui promet se joue rarement dans le choix du modèle. Elle se joue dans la discipline des neuf phases — et elle se voit dès la première semaine.