Anatomie d’un projet IA de bout en bout : les neuf phases

AIDE À LA DÉCISION · POINTS DE DÉCISION

Chaque étape doit mériter la suivante

Les neuf phases ne sont pas une liste à cocher. Chacune lève une incertitude différente et protège l’investissement suivant.

01L’incertitude levée à chaque phase

01Intentionobjectif flou

02Mesure de départrien n’est mesuré

03Portefeuillemauvais premier cas

04Architecturefrontières floues

05Fondationsimpossible de tester

06Piloteprocessus non éprouvé

07Preuvecause incertaine

08Mise en productionexploitation fragile

09Valeurportefeuille qui dérive

Pas de preuve, pas d’étape suivante. Revenir à une phase précédente est un apprentissage, pas un échec.

La plupart des bilans de projets IA se trompent de coupable. Le rapport final accuse le modèle : pas assez précis, pas assez fiable, « pas prêt pour notre métier ». Dans nos missions, nous constatons presque toujours autre chose. Le modèle fonctionnait. Ce qui manquait, c’est une phase entière du projet : personne n’avait mesuré le processus avant de le modifier, personne n’avait défini ce qui justifierait un arrêt, personne n’avait construit d’environnement d’essai 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 l’absence de méthode en général : les organisations savent mener des projets. C’est que l’IA déplace le risque vers des endroits inhabituels. La qualité est probabiliste, la preuve exige une mesure de départ, les droits d’accès deviennent une question d’architecture et la valeur ne tient pas sans suivi. D’où cette méthode, tirée de nos missions : l’anatomie complète d’un projet IA d’entreprise, en neuf phases.

La méthode 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, la mise en production, la valeur dans la durée. 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 : cela le repousse là où il coûte plus cher.

L’ordre n’interdit pas les allers-retours : un pilote peut renvoyer à l’architecture, une preuve peut rouvrir le portefeuille. Mais les décisions, elles, sont ordonnées : on ne choisit pas une solution technique avant d’avoir choisi un problème, et on n’étend pas un système avant d’avoir compté ses erreurs.

La méthode vaut pour un assistant documentaire comme pour un agent qui agit en production ; seul le poids 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 envers des clients passe plus de temps en architecture, en fondations et en pilote. Sauter une phase ne fait jamais gagner de temps : cela transfère une dette vers la production.

DÉCIDER

1. Intention
2. Mesure de départ
3. Portefeuille

CONSTRUIRE

4. Architecture
5. Fondations
6. Pilote

PROUVER ET ÉTENDRE

7. Preuve
8. Mise en production
9. Valeur

Chaque phase a un critère de sortie.

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 commanditaire, 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 processus à changer, un commanditaire nommé qui réserve réellement du temps, le budget de la phase de preuve et le critère d’abandon écrit.

Le piège classique. Le projet par imitation : on lance parce qu’un concurrent a fait une annonce, sans problème à soi. Le commanditaire est un nom sur une présentation, pas une personne qui tranchera le moment venu.

Critère de sortie. Le commanditaire énonce sans notes le résultat à changer et les conditions d’arrêt, et les deux figurent dans un document qu’il a signé.

Phase 2 : le diagnostic et la mesure de départ

On ne peut pas améliorer un processus qu’on n’a pas mesuré ; on peut seulement le changer. La phase 2 décrit le travail réel, pas le processus officiel : qui fait quoi, où le temps se perd, où se concentre le travail refait, quelles données circulent et sous quelles contraintes légales. C’est aussi le moment de figer la mesure de départ qui rendra toute preuve possible.

Livrables. Une description du processus tel qu’il est pratiqué ; des mesures chiffrées (délai, taux de travail refait, taux d’exceptions, coût par dossier, écarts de qualité) ; un inventaire des données et des logiciels concernés, avec leurs responsables.

Le piège classique. Mesurer après coup. Sans mesure de départ, 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 : décrire le processus du manuel qualité, que personne ne suit.

Critère de sortie. Vous savez ce que le processus coûte aujourd’hui, chiffres à l’appui, et 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 d’autres. La phase 3 réunit plusieurs candidats et les note sur trois critères : le gain (ampleur économique, effet pour les utilisateurs, importance stratégique), l’effort (accès aux données, complexité des connexions, contrôles nécessaires, possibilité d’essayer) et le risque (données en jeu, conséquence d’une erreur). Le premier cas n’est pas celui qui promet le plus, mais celui qui combine un gain significatif et le chemin le plus court vers une preuve fiable.

Livrables. Un portefeuille noté sur le gain, l’effort et le risque ; un premier cas choisi et documenté ; la liste des cas écartés, avec la raison de leur report, qui évitera de rejouer le même débat chaque trimestre.

Le piège classique. Choisir le cas le plus spectaculaire : souvent face aux clients, 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. Le commanditaire, le responsable du processus 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, quels droits s’appliquent, quelle solution technique porte le cas, et ce qui reste réversible. Sur le choix de la solution, notre règle rejoint les travaux publiés par Anthropic sur la construction d’agents : commencer par la solution la plus simple qui suffit (un appel à un outil, une suite de consignes, un aiguillage) et ne passer à un agent autonome que si le cas l’exige de façon démontrée. Côté intégration, des standards ouverts comme le Model Context Protocol réduisent la dépendance aux fournisseurs et préparent la réversibilité.

Livrables. Un schéma des flux de données avec leurs responsables ; un modèle de droits où le système hérite des droits de l’utilisateur, jamais plus ; un choix de solution justifié par écrit ; une analyse de réversibilité : ce que coûterait un changement de modèle ou de fournisseur.

Le piège classique. En faire trop : construire un agent autonome là où une suite de consignes suffisait, puis passer des mois à corriger une autonomie dont personne n’avait besoin. Le piège inverse existe aussi : ignorer les droits d’accès et découvrir en pilote que l’assistant montre des documents que l’utilisateur n’aurait jamais dû voir.

Critère de sortie. Chaque donnée qui entre dans le système ou en sort a un chemin documenté, un responsable et une frontière d’accès vérifiable.

Phase 5 : les fondations

La phase 5 construit ce qui ne se voit pas dans une démonstration : des identités et des accès bien attribués, des connexions de données fiables, des contrôles d’exploitation et, surtout, l’environnement d’essai. C’est lui qui distingue un projet piloté d’un projet à l’aveugle : un jeu de cas réels, représentatifs et volontairement difficiles, rejouable à chaque modification. Le cadre de gestion des risques de l’IA du NIST dit la même chose à sa manière : on ne gouverne que ce qu’on sait décrire et mesurer.

Livrables. Des comptes techniques aux droits minimaux ; des accès aux données opérationnels et journalisés ; un jeu d’essais 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’essai pour « aller plus vite au pilote ». L’équipe modifie ensuite les consignes 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 rejouer votre jeu d’essais et obtenir un résultat reproductible avant qu’un seul utilisateur réel ait touché le système.

Phase 6 : le pilote supervisé

Le pilote ne teste pas la technologie : il teste le processus modifié, ses contrôles et les personnes qui le font. La phase 6 ouvre le système à un périmètre restreint et nommé, avec une validation humaine systématique au départ, puis par échantillon à mesure que la confiance se construit sur des faits. Chaque erreur est classée : gravité, cause, facilité à la détecter. C’est ce décompte des erreurs, et non l’enthousiasme des premiers utilisateurs, qui alimentera la décision de la phase 7. La supervision n’est pas de la méfiance envers le système : c’est l’instrument qui permettra de l’alléger, preuves en main.

Livrables. Un périmètre écrit (utilisateurs nommés, cas couverts, cas explicitement exclus) ; un circuit de validation humaine avec ses règles d’échantillonnage ; un registre des erreurs classées ; des seuils de qualité fixés avant le lancement, pas après.

Le piège classique. Le pilote vitrine : 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 disposez d’un taux d’erreur mesuré par type de cas et comparé à la mesure de départ 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 réunion de décision, pas une célébration. Trois issues sont légitimes : étendre, parce que les seuils sont atteints ; ajuster, parce que la valeur existe mais ailleurs ou autrement ; arrêter, parce que les preuves manquent, en gardant ce qu’on a appris. Un arrêt décidé sur preuves est un succès de pilotage ; une extension par inertie est un échec reporté. Le gain se chiffre par l’écart entre les résultats du pilote et la mesure de départ de la phase 2 : c’est elle qui transforme une estimation en fait.

Livrables. Un dossier de preuve : écart par rapport à la mesure de départ, coûts complets (construction, exploitation, supervision), incidents et leur résolution, usage réel ; une décision écrite (étendre, ajuster ou arrêter) signée par le commanditaire.

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. L’arrêt n’a jamais été une option réelle, seulement une ligne sur une présentation.

Critère de sortie. La décision est prise sur chiffres, signée, et l’arrêt était réellement sur la table.

Phase 8 : la mise en production

Mettre en production n’est pas la fin du projet : c’est le début de l’exploitation. La phase 8 transforme un pilote qui marche en un service qui tient : suivi (traces, coût par requête, baisse de qualité), organisation de l’exploitation (qui répond quand ça casse, avec quels engagements), maîtrise des coûts et formation des équipes au nouveau processus, pas seulement à l’outil. C’est ici que se joue la durabilité économique : un coût par requête accepté en pilote peut devenir indéfendable en volume si personne ne le surveille.

Livrables. Des tableaux de suivi en production ; une procédure d’exploitation avec un responsable nommé ; des budgets et des alertes de coûts ; un plan de formation ancré dans le processus ; la revue de sécurité avant mise en production.

Le piège classique. La passation fantôme : l’équipe projet passe au sujet suivant, personne n’est d’astreinte, les coûts dérivent en silence et la qualité se dégrade sans témoin. Le système meurt en production, lentement, sans que personne ne le constate.

Critère de sortie. Le système a un responsable d’exploitation nommé, un budget suivi et une qualité mesurée en continu, pas seulement les jours d’incident.

Phase 9 : la valeur dans la durée

La dernière phase n’a pas de fin : c’est le régime permanent. Les mesures sont refaites à intervalle régulier, parce que le processus, les volumes et les modèles changent. Une revue 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 mesures refaites et datées ; une revue mensuelle à ordre du jour fixe (valeur, coûts, incidents, risques, décisions) ; une règle de réinvestissement qui relie les gains prouvés aux cas suivants.

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

De la méthode 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’une soixantaine de pages, tiré d’une mission réelle : il déroule les neuf phases livrable par livrable, de la note d’intention aux revues mensuelles, avec les modèles de documents et les seuils utilisés.

Deux règles résument l’usage de la méthode. Ne sautez aucune phase : chacune existe parce que son absence a un coût. 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

1. Nommez le commanditaire et faites-lui écrire le critère d’abandon, avant toute conversation sur les outils.
2. Choisissez un processus et mesurez-le pendant une à deux semaines : délai, travail refait, exceptions, coût par dossier.
3. Notez trois à cinq cas candidats sur le gain, l’effort et le risque, et n’en retenez qu’un.
4. Dessinez sur une page les flux de données et les droits d’accès du cas retenu.
5. Constituez un jeu d’essais à partir de cas réels, y compris les cas difficiles, avant d’écrire la moindre consigne.
6. Fixez par écrit les seuils de qualité du pilote et la date de la décision d’étendre, d’ajuster ou d’arrêter.
7. Réservez dès maintenant la revue mensuelle dans les agendas : un suivi qui n’est pas planifié 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.

Comment nous pouvons aider

Les phases 1 à 3 se préparent avec vos directions dans le cadre de l’Accompagnement IA. Les phases 4 à 9, de l’architecture à la mise en production et au suivi, relèvent de l’offre Engineering IA : cadrage de une à trois semaines, puis devis ferme, ou abonnement si plusieurs chantiers s’enchaînent. Pour une PME, la version courte de cette méthode est le pilote de 30 jours.