Roadmap 90 jours

Pourquoi caler un calendrier plutôt que de laisser le POC s'étirer

Un backlog ouvert est le meilleur allié de l'échec silencieux. Sans échéance ni critère de sortie, un POC IAintelligence artificielleIAEnsemble des techniques permettant à un programme d'accomplir une tâche qui demanderait de l'intelligence humaine. Le terme couvre aussi bien les systèmes à règles écrites que ceux qui apprennent de données.Voir dans le glossaire a tendance à s'étirer indéfiniment : on ajoute un cas d'usage, on peaufine un promptpromptIAConsigne ou contexte fourni à un modèle de langage pour orienter sa réponse. La qualité du prompt conditionne souvent la qualité du résultat.Voir dans le glossaire, on attend « encore une itération » avant de montrer le résultat à un vrai utilisateur. Ce chapitre propose un calendrier de référence sur 90 jours, découpé en trois phases de 30 jours séparées par trois portes de décision explicites, pour transformerTransformerIAArchitecture introduite en 2017, fondée sur le mécanisme d'attention, qui traite une séquence entière en parallèle. Elle sert de base à tous les grands modèles de langage actuels.Voir dans le glossaire les principes des chapitres précédents — cadrage par job-to-be-done, choix de stack, UX de confiance, métriques, éthique, scale — en un plan opérationnel daté.

Ce n'est pas une méthode miracle, mais un gabarit calibré sur l'expérience répétée de projets IA en entreprise : la majorité des POC qui aboutissent à un produit utilisé suivent un rythme proche de celui-ci, et la majorité des POC qui s'enlisent le font en l'absence de portes de décision datées.

Ce qui compte n'est pas la durée exacte mais la structure : trois phases à objectif distinct, chacune fermée par une décision explicite go/no-go/itère. Un contextefenêtre de contexteIAQuantité de texte qu'un modèle peut prendre en compte simultanément : question, documents fournis et historique. Au-delà, les éléments les plus anciens sortent du champ.Voir dans le glossaire réglementé (santé, finance, juridique) peut légitimement doubler chaque phase. Un cas d'usage interne à faible enjeu peut la compresser à 45 jours. Ce qui ne doit jamais disparaître, quelle que soit la durée réelle, c'est l'existence de la porte elle-même — la tentation la plus fréquente est de la sauter plutôt que de l'allonger.

Vue d'ensemble des trois phases

Le calendrier répond à une question différente à chaque étape. La phase 1 demande : cette tâche tolère-t-elle un système probabiliste, et un prototype le prouve-t-il sur des cas réels ? La phase 2 demande : ce prototype survit-il au contact d'utilisateurs réels, hors du regard bienveillant de l'équipe qui l'a construit ? La phase 3 demande : le système tient-il la charge, le coût et la gouvernance d'un produit en production continue ?

Un point mérite d'être souligné avant le détail de chaque phase : le même jeu de cas de test doit servir de référence sur les 90 jours. Changer d'échantillon à chaque phase donne l'illusion d'un progrès qui n'est qu'un changement de règle du jeu — un piège détaillé plus loin.

Jours 0-30 : cadrer et prouver (POC)

L'objectif n'est pas de construire un produit, mais de répondre à une seule question : la tâche identifiée au cadrage tolère-t-elle réellement un système génératif, sur des cas concrets et non des exemples choisis pour bien fonctionner ?

Le déroulé tient en quatre blocs d'une semaine :

• Semaine 1 — cadrage resserré. Reformulation du job-to-be-done, choix d'un unique cas d'usage prioritaire, constitution d'un premier jeu de 30 à 50 cas réels représentatifs, y compris des cas difficiles signalés par les utilisateurs métier.
• Semaine 2 — premier prototype. Stack minimal (modèle, éventuellement récupération de contexte), sans investissement d'infrastructure de production. L'objectif est un prototype qui répond, pas un prototype qui scale.
• Semaine 3 — confrontation aux cas réels. Exécution du prototype sur l'intégralité du jeu de cas de la semaine 1, avec évaluation qualitative par une personne métier — pas seulement par l'équipe technique, qui a un biaisbiaisIARégularité correctement apprise dans des données qui ne représentent pas la réalité visée, ou qui enregistrent des décisions passées avec leurs préjugés. Changer d'algorithme ne le corrige pas.Voir dans le glossaire de complaisance envers son propre système.
• Semaine 4 — durcissement minimal. Correction des défaillances les plus flagrantes, rédaction d'un rapport de POC synthétique (taux de succès, coût par requête observé, limites identifiées) destiné au sponsor métier.

Définissez le critère de réussite — par exemple « au moins 80 % des cas traités correctement, sans erreur grave sur les 20 % restants » — avant de commencer à construire. Un seuil fixé après coup se plie presque toujours aux résultats obtenus, ce qui annule sa fonction de garde-fou.

À la fin de cette phase, trois issues sont légitimes : le POC dépasse le seuil fixé et mérite un pilote ; il échoue clairement et le projet s'arrête — un succès de cadrage, pas un échec, mieux vaut le découvrir en 30 jours qu'en 90 ; ou il reste ambigu et mérite deux semaines ciblées sur un point précis, pas un redémarrage complet.

Porte de décision 1 : le POC mérite-t-il un pilote ?

Cette porte se tranche sur des critères écrits, pas sur une impression de démo :

1. Le taux de succès sur le jeu de cas réels atteint-il le seuil fixé en semaine 1 ?
2. Les échecs sont-ils tolérables (reformulation à revoir) ou structurels (la tâche ne tolère pas un système probabiliste) ?
3. Le coût par requête observé reste-t-il dans un ordre de grandeur compatible avec le modèle économique visé ?

Si la réponse est positive aux trois, le projet passe en pilote. Si la deuxième révèle un problème structurel, il faut revenir au cadrage plutôt que corriger par plus de prompt engineeringprompt engineeringIADiscipline consistant à concevoir des instructions précises pour guider un LLM vers la réponse souhaitée. Elle inclut les techniques de chain-of-thought, few-shot, rôle et format de sortie.Voir dans le glossaire — un signe classique de ce blocage est une équipe qui rallonge indéfiniment un prompt système sans jamais faire remonter le taux de succès durablement.

Jours 30-60 : durcir et instrumenter (pilote)

Le pilote change de nature par rapport au POC : il expose le système à des utilisateurs réels, hors du regard de l'équipe projet, sur un périmètre restreint mais réel — une équipe, un segment de clients, une région. C'est la phase où apparaissent les défauts invisibles en interne : formulations inattendues, cas d'usage détournés, réactions à une réponse jugée froide ou trop mécanique.

Le travail se répartit sur trois axes :

• UX de confiance. Signaux de fiabilité (niveau de certitude affiché, sources citées, possibilité de correction) et chemin de repli clair quand le système ne sait pas répondre, plutôt qu'une réponse fausse et assurée.
• Instrumentation. Suivi des métriques produit — taux de résolution, taux d'escalade, satisfaction, coût par requête — avec un tableau de bord consultable quotidiennement, pas seulement en fin de phase.
• Boucle de retour. Collecte des cas d'échec signalés par les utilisateurs pilotes, alimentant le jeu de cas de test constitué en semaine 1 — le début du data flywheel, ici à petite échelle.

Une équipe pressée par le calendrier transforme parfois le pilote en simple prolongation du POC : mêmes utilisateurs internes, aucune instrumentation nouvelle. Le risque n'est pas seulement de perdre du temps — c'est de découvrir en semaine 9 des défauts qu'un vrai pilote aurait révélés en semaine 6, à un coût de correction bien plus faible.

Le périmètre du pilote doit rester volontairement restreint — quelques centaines à quelques milliers d'utilisateurs selon le contexte — pour que les incidents restent gérables. Un pilote ouvert à l'ensemble des utilisateurs finaux n'est plus un pilote, c'est un lancement non préparé.

Une équipe RH pilote un assistant de présélection de CV sur 200 candidatures internes pendant deux semaines au lieu de quatre, pressée par une annonce de lancement déjà communiquée à la direction. Le pilote ne détecte pas un biais de formulation qui pénalise les candidatures au style non conventionnel. Le défaut apparaît en semaine 11, après ouverture à l'ensemble du recrutement, et déclenche un audit correctif en urgence — un coût largement supérieur aux deux semaines économisées.

Porte de décision 2 : le pilote est-il scalable ?

Cette porte reprend les trois dimensions du passage à l'échelle — performance, coûts, organisation — et vérifie qu'aucune n'a été laissée de côté pendant que l'équipe se concentrait sur la qualité fonctionnelle :

Si l'une de ces quatre lignes est rouge, la bonne décision est de prolonger le pilote de deux à quatre semaines sur ce point précis, pas de lancer quand même en espérant que « ça se réglera en production ».

Jours 60-90 : lancer et monter en charge progressivement

La dernière phase ne consiste pas à ouvrir l'accès à tous les utilisateurs le même jour. Un rollout progressif — 10 % du volume cible en semaine 9, 30 % en semaine 10, 100 % en semaine 12, avec un palier de stabilisation avant chaque montée — détecte un problème de charge, de coût ou de qualité avant qu'il n'affecte l'ensemble des utilisateurs.

Trois activités la structurent :

• Semaines 9-10 — rollout initial. Ouverture progressive avec surveillance renforcée : vérification quotidienne des métriques, astreinte dédiée, seuils d'alerte resserrés par rapport au régime de croisière.
• Semaine 11 — durcissement final. Correction des derniers défauts détectés en rollout, mise en place du mode dégradé en cas de panne fournisseur, si ce n'est pas déjà fait.
• Semaines 12-13 — stabilisation et transfert. Passage en régime d'exploitation normale, seuils d'alerte définitifs, et transfert formel de la propriété du produit vers l'équipe qui en aura la charge continue.

Un produit à faible enjeu (résumé interne, brouillon de communication) peut monter en charge en une semaine. Un produit à enjeu réglementaire ou financier mérite un rollout étalé sur plusieurs semaines, avec des paliers plus fins, quitte à repousser la date de généralisation au-delà du jour 90.

Porte de décision 3 : généraliser ou itérer encore ?

Cette dernière porte ne clôt pas le projet — elle marque la bascule d'un mode projet à un mode d'exploitation continue. Trois questions la structurent : le rollout a-t-il révélé des problèmes non anticipés lors du pilote ? Les métriques de production sont-elles stables sur au moins une semaine complète à pleine charge ? L'équipe d'exploitation dispose-t-elle des outilstool callingIACapacité d'un agent ou d'un LLM à invoquer des outils externes (API, calcul, recherche) pendant le raisonnement.Voir dans le glossaire de surveillance et de rollback nécessaires pour opérer sans l'équipe projet initiale ?

Une réponse positive aux trois déclenche la généralisation complète. Une réponse négative signifie qu'une itération ciblée et datée doit précéder la généralisation — le même principe que les deux portes précédentes.

Répartition des rôles sur les 90 jours

La charge et la nature du travail changent significativement d'une phase à l'autre, avec des implications directes sur la composition de l'équipe :

Une erreur fréquente est de garder la même composition d'équipe sur les trois phases, en particulier l'ingénieur qui a construit le prototype comme seul point de contact pendant le lancement. Le pilote et le lancement demandent des compétences d'observabilité et de gestion d'incident qui ne sont pas nécessairement celles qui ont produit le meilleur prototype.

Anti-patterns de calendrier

• Changer de jeu de cas de test à chaque phase. Si les cas utilisés en pilote ne sont pas un sur-ensemble de ceux du POC, la comparaison perd son sens : une amélioration apparente peut n'être qu'un changement de référentiel.
• Sauter la phase pilote pour gagner du temps. Passer directement d'un POC réussi en environnement contrôlé à un lancement général revient à découvrir en production ce qu'un pilote restreint aurait révélé à moindre coût.
• Laisser une porte de décision glisser sans arbitrage formel. Un « on verra en avançant » à la place d'un go/no-go écrit transforme la roadmap en simple étiquetteétiquetageIATravail consistant à associer à chaque exemple la réponse attendue. C'est presque toujours le poste le plus coûteux d'un projet d'apprentissage supervisé.Voir dans le glossaire de dates.
• Communiquer une date de lancement avant la porte 2. Annoncer publiquement une date de disponibilité avant d'avoir validé que le pilote est scalable crée une pression qui pousse à lancer malgré des signaux d'alerte.
• Confondre stabilisation et généralisation. Une semaine sans incident sur 10 % du volume ne garantit pas la même chose à 100 %.

Checklist de fin de roadmap

Avant de considérer les 90 jours terminés et le produit transféré en exploitation normale :

• Le jeu de cas de test constitué en semaine 1 a été enrichi mais jamais remplacé, sur l'ensemble des trois phases.
• Chacune des trois portes de décision a fait l'objet d'un arbitrage écrit et daté, avec les critères effectivement mesurés en regard des seuils fixés à l'avance.
• Le rollout de la phase 3 s'est déroulé par paliers, avec un point de stabilisation observé avant chaque montée en charge.
• Un propriétaire nommé du prompt, des métriques de qualité et du budget d'inférenceinférenceIAUtilisation d'un modèle déjà entraîné sur une donnée nouvelle. Peu coûteuse à l'unité mais répétée à chaque requête, elle constitue le coût récurrent d'exploitation.Voir dans le glossaire est identifié pour l'exploitation continue.
• Un mode dégradé et un plan de rollback existent et ont été testés au moins une fois avant la généralisation complète.
• Les retours utilisateurs collectés pendant le pilote et le lancement alimentent un processus continu, pas un rapport archivé après le jour 90.

Ce qu'il faut retenir

Une roadmap de 90 jours ne garantit pas le succès d'un produit IA ; elle garantit que l'équipe se pose les bonnes questions au bon moment, avec des critères écrits plutôt qu'une impression de progrès. La structure compte plus que la durée exacte : trois phases à objectif distinct, un jeu de cas de test stable, et trois portes de décision pouvant aboutir à un arrêt, une itération ou une poursuite — les trois étant des issues légitimes. C'est ce filtre, appliqué avec discipline, qui distingue un produit IA qui atteint la production d'un POC resté indéfiniment prometteur.