Construire une feuille de route IA priorisée par le ROI
La plupart des plans IA échouent parce qu’ils empilent des idées au lieu de les arbitrer. Voici la méthode pour transformer une liste de cas d’usage en une feuille de route défendable, séquencée par la valeur réelle et la faisabilité.
Qu’est-ce qu’une feuille de route IA priorisée par le ROI ?
En une phrase : une feuille de route IA priorisée par le ROI est un document d’arbitrage qui range chaque cas d’usage selon sa valeur métier nette rapportée à l’effort et au risque, et qui dit dans quel ordre les lancer.
Ce n’est donc ni un catalogue de cas d’usage ni une liste d’outils à déployer. C’est un document d’arbitrage : il dit ce que vous faites, dans quel ordre, avec quelles ressources, et surtout ce que vous ne faites pas cette année. Sa logique de priorisation tranche par la valeur métier nette plutôt que par l’enthousiasme du moment ou la dernière démo impressionnante.
Le piège classique du dirigeant ou du DSI : confondre vision (« devenir une entreprise pilotée par l’IA ») et plan exécutable (« automatiser le tri des demandes SAV au T3, ROI estimé 9 mois »). La vision donne le cap ; la feuille de route donne les coordonnées. Une démarche de cadrage la construit en quatre couches : ambition cadrée sur le business, portefeuille de cas d’usage scorés, séquencement quick wins / chantiers structurants, et prérequis (données, infra, compétences, gouvernance). Une feuille de route sans la quatrième couche reste un vœu pieux.
Principe directeur : on ne priorise pas des technologies, on priorise des problèmes métier dont la résolution a une valeur chiffrable. L’IA est le moyen, pas la fin. Si un cas d’usage ne se rattache pas à un indicateur que le COMEX suit déjà (marge, délai, NPS, coût de traitement), il n’a probablement rien à faire en haut de la liste.
Stratégie IA dirigeant / DSI : qui décide quoi ?
Quel est le rôle du binôme dirigeant et DSI ?
Une feuille de route IA n’est solide que si elle est portée par le binôme dirigeant et DSI. La stratégie IA d’un dirigeant ou d’un DSI ne se joue pas sur le choix d’un modèle mais sur trois décisions : quelles priorités stratégiques l’IA doit servir, quel budget et quel rythme y consacrer, et quel niveau de risque l’entreprise accepte (conformité, dépendance fournisseur, qualité des données). Le dirigeant arbitre la valeur et l’ambition ; le DSI garantit la faisabilité, l’infrastructure et la gouvernance. Quand ces deux rôles signent le même document, la feuille de route survit aux arbitrages budgétaires. Quand l’un des deux est absent, elle reste un slide. C’est précisément l’alignement qu’une mission de diagnostic & cadrage permet d’outiller.
Comment construire la feuille de route, étape par étape ?
Voici la séquence appliquée en mission de cadrage. Elle tient en cinq étapes et se boucle en quelques semaines, pas en six mois de comité. Comptez en pratique trois à six semaines selon la taille de l’organisation.
Cadrer l’ambition et l’aligner sur le business
Partez des objectifs du COMEX, pas de la techno. Trois à cinq priorités stratégiques maximum (réduire le coût de traitement, accélérer le time-to-market, améliorer la rétention). Chaque cas d’usage devra plus tard se raccrocher explicitement à l’une d’elles. Sans cet ancrage, vous ne pourrez jamais défendre vos arbitrages. Durée indicative : 3 à 5 jours.
Identifier le portefeuille de cas d’usage
Collectez largement (ateliers métier, irritants terrain, process mining) puis dédupliquez. Le process mining apporte ici une mesure objective : il reconstitue le déroulé réel des processus à partir des logs de vos systèmes (ERP, CRM, ticketing) et chiffre les volumes, fréquences, temps de cycle et goulots. Vous priorisez alors sur des faits, pas sur des impressions de terrain. Visez 15 à 30 candidats formulés en problème + bénéfice attendu, pas en solution. Durée indicative : 1 à 2 semaines.
Scorer chaque cas : valeur, faisabilité, effort
Notez chaque candidat sur trois axes (1 à 5). Valeur = gain métier annualisé et stratégique. Faisabilité = disponibilité des données, maturité technique mesurée par des évals, risque de conformité (« peut-on le faire ? »). Effort = charge build/run et dépendances (« combien ça coûte ? »). Un score transparent coupe court aux débats d’opinion. Durée indicative : 3 à 5 jours.
Positionner sur la matrice valeur / faisabilité
Croisez valeur et faisabilité pour faire émerger les quick wins (haute valeur, haute faisabilité) et les chantiers structurants (haute valeur, faisabilité à construire). Séquencez : les quick wins financent et crédibilisent les chantiers lourds. Durée indicative : 2 à 3 jours.
Chiffrer ROI, prérequis et séquençage
Pour le top 5 à 8, estimez gains et coûts complets (build, LLM, infra, run, change). Listez les prérequis bloquants (qualité des données, accès aux systèmes, compétences). Le résultat : un planning trimestriel avec jalons et critères de go/no-go. Durée indicative : 1 semaine.
Cette démarche est au cœur de l’offre Conseil & stratégie IA de ianos : la mission se clôt sur cette feuille de route signée par le COMEX, pas sur un PowerPoint d’intentions.
Comment prioriser les cas d’usage IA par le ROI ?
Quels critères mettre dans la matrice valeur / faisabilité ?
La matrice valeur / faisabilité est un tableau à deux axes qui positionne chaque cas d’usage selon sa valeur métier (vertical) et la facilité à le réaliser (horizontal), pour faire émerger visuellement par quoi commencer. Elle n’a de valeur que si les axes sont décomposés en sous-critères explicites. Sinon chacun note « à l’instinct » et la priorisation devient une bagarre politique. Voici la grille de scoring recommandée, chaque sous-critère étant noté de 1 à 5.
| Axe | Sous-critères à noter (1 à 5) | Ce qu’un score élevé signifie |
|---|---|---|
| Valeur | Gain financier annualisé (heures économisées × coût horaire, marge récupérée, churn évité), impact stratégique, volume et fréquence du processus, réplicabilité sur d’autres équipes. | Bénéfice métier chiffrable, élevé et duplicable. |
| Faisabilité (« peut-on le faire ? ») | Disponibilité et qualité des données, accès technique aux systèmes sources, maturité du modèle pour la tâche (validée par des évals sur vos données réelles), niveau de risque RGPD / AI Act, tolérance du métier à l’erreur. | Donnée prête, modèle au niveau, risque maîtrisé. |
| Effort (« combien ça coûte ? ») | Charge de build, dépendances inter-équipes, coût de run récurrent (tokens LLM, infra, supervision), charge de conduite du changement et d’adoption. | Attention : ici un score élevé est défavorable (il divise la priorité). |
Un calcul simple et défendable : score de priorité = (Valeur × Faisabilité) / Effort. Le produit valeur × faisabilité évite de promouvoir un cas d’usage à forte valeur mais infaisable, ou très faisable mais sans intérêt. La division par l’effort fait remonter les quick wins. Une précision pour éviter une critique légitime : la faisabilité répond à « peut-on le faire ? » (la donnée existe-t-elle, le modèle est-il au niveau, le risque est-il acceptable) tandis que l’effort répond à « combien ça coûte à produire et à opérer ? ». Un cas peut être parfaitement faisable (donnée propre, modèle mûr) tout en demandant un effort lourd (intégrations multiples, fort volume de tokens) ; gardez les deux axes étanches pour ne pas compter deux fois la même chose. Une fois chaque candidat noté, vous le positionnez sur la matrice.
| Faisabilité haute | Faisabilité à construire | |
|---|---|---|
| Valeur haute | Quick wins — à lancer en premier, en production sous 3-4 mois. Ils financent et crédibilisent le reste. | Chantiers structurants — fort ROI mais prérequis lourds (données, plateforme). À séquencer avec jalons sur 6-12 mois. |
| Valeur basse | Optionnels — petits gains rapides, à faire si capacité résiduelle, sans mobiliser le COMEX. | À écarter — coûteux et peu utiles. Documentez la décision pour éviter d’y revenir chaque trimestre. |
Un exemple chiffré de ROI, déroulé de bout en bout
Prenons un cas d’usage réel et anonymisé issu de missions de cadrage, dans une ETI de services B2B : l’automatisation du tri et de la pré-qualification des demandes SAV entrantes via un agent LLM gouverné. L’équipe SAV concernée compte 6 conseillers de niveau 1 (support généraliste) sur un volume d’environ 9 000 demandes mensuelles.
| Poste | Détail du calcul | Montant |
|---|---|---|
| Gain brut annuel | 6 conseillers × 2 h/jour de tri × 220 jours = 2 640 h/an ; agent automatise 70 % = 1 848 h économisées, à 38 €/h chargé. | +70 224 €/an |
| Coût de build (one-shot) | Conception, intégration au ticketing, garde-fous et évals : ~45 j-h à 650 € de TJM. | −29 250 € |
| Coût de run annuel | Tokens LLM (~600 €/mois) + infra et supervision (~400 €/mois) + évals et maintenance (~300 €/mois) = 1 300 €/mois. | −15 600 €/an |
| ROI net année 1 | 70 224 − 29 250 − 15 600. | +25 374 € |
| ROI net année 2+ | Gain brut − run, build amorti. | ~+54 600 €/an |
| Point mort (steady-state) | Au régime stabilisé, gain net mensuel ~4 552 € ((70 224 − 15 600)/12) face à 29 250 € de build, soit 29 250 / 4 552 ≈ 6,4 mois. | vers le 7e mois |
Un point d’honnêteté méthodologique : le point mort « vers le 7e mois » vaut au régime stabilisé (gain net mensuel ~4 552 €). Comme l’agent monte en charge progressivement, les premiers mois rapportent mécaniquement moins, ce qui décale le point mort réel au-delà de ce calcul théorique. C’est un point mort optimiste assumé, à présenter comme tel devant un COMEX. Sur ce cas, l’estimation initiale tablait sur 60 % d’automatisation ; après le premier quick win en production, l’agent a tenu 70 % une fois les évals affinées sur les motifs récurrents — d’où un ROI nettement meilleur que le business case d’origine. Le détail importe moins que la discipline : un cas d’usage ne monte en haut de la feuille de route que s’il tient ce type de calcul, prérequis données compris. Le coût horaire chargé de 38 €/h (conseiller SAV niveau 1) et le TJM de 650 € (profil intégration/IA) sont des ordres de grandeur France 2025 à recalibrer sur votre grille et votre niveau de séniorité. Une fourchette assumée vaut mieux qu’une fausse précision — l’objectif est un ordre de grandeur défendable, pas une comptabilité analytique au centime.
Quick wins ou chantiers structurants : par quoi commencer ?
Commencez par un ou deux quick wins visibles sur les trois à quatre premiers mois. Ils ont une triple fonction : prouver la valeur à un COMEX souvent sceptique, roder votre chaîne de mise en production, et financer politiquement les chantiers lourds. Mais ne restez pas bloqué en mode quick win : si au bout d’un an vous n’avez que des automatisations isolées, vous avez fait du saupoudrage, pas de la transformation. Les chantiers structurants (refonte d’un processus de bout en bout, plateforme data, agents multi-étapes) se lancent en parallèle, avec un horizon de 6 à 12 mois et des jalons intermédiaires.
Le risque inverse existe aussi : lancer un chantier structurant trop tôt, avant d’avoir une équipe rodée et une donnée propre. C’est l’erreur la plus coûteuse observée sur le terrain. Pour cadrer la qualité et la disponibilité de vos données avant de vous engager, lisez le guide Cartographier ses données pour l’IA.
Build vs buy : faut-il développer ou acheter une solution IA ?
Le build vs buy est l’arbitrage entre développer une solution IA en interne (build) et souscrire à une solution existante (buy), avec l’assemblage de briques comme voie intermédiaire. La règle pragmatique : achetez la commodité, construisez l’avantage différenciant. Un assistant de rédaction d’e-mails ou une transcription de réunions sont des commodités : un éditeur fait mieux et moins cher que vous. En revanche, un agent qui orchestre votre processus métier, sur vos données, avec vos règles de gouvernance, c’est de l’avantage compétitif : il se construit. Entre les deux, l’assemblage (briques open source orchestrées) couvre la majorité des cas d’usage d’entreprise.
- Buy si le besoin est standard, non différenciant, et qu’un SaaS conforme existe — vous achetez du time-to-value.
- Build / assemble si le processus est cœur de métier, si la donnée est sensible, ou si l’intégration profonde au SI crée la valeur.
- Méfiez-vous du faux « buy » : un outil acheté mais lourdement personnalisé cumule le coût de licence et le coût de build. C’est souvent le pire des deux mondes.
Comment choisir un LLM pour l’entreprise ?
Il n’y a pas un « meilleur modèle » mais un modèle par usage. Quatre critères structurent le choix : performance sur votre tâche réelle (mesurée par des évals, pas par les benchmarks marketing), coût au volume attendu, confidentialité / souveraineté des données, et latence.
Quelques repères chiffrés mi-2026 pour rendre ces critères concrets (ordres de grandeur, à revérifier car ils bougent vite) : les modèles haut de gamme via API se situent autour de quelques euros par million de tokens en entrée et jusqu’à plusieurs dizaines d’euros par million en sortie, là où un petit modèle « volume » coûte souvent moins d’un euro le million de tokens — un écart de un à deux ordres de grandeur qui justifie à lui seul une architecture mixte. Côté fenêtre de contexte, les modèles courants offrent de 128 000 à plusieurs centaines de milliers de tokens (utile pour ingérer un dossier entier sans découpage). Côté latence, comptez typiquement de l’ordre de la seconde pour une réponse courte en API ; un usage temps réel (chat client) et un usage batch (classification de 9 000 tickets la nuit) n’imposent pas du tout les mêmes contraintes.
Attention à ne pas confondre deux axes distincts. Le premier est le mode d’accès : modèle consommé via API managée (vous ne gérez pas l’infra) ou modèle auto-hébergé (vous l’opérez sur votre infra, AWS ou on-premise). Le second est la licence : modèle à poids fermés ou modèle à poids ouverts. Ces axes se recoupent imparfaitement : un éditeur comme Mistral propose à la fois des modèles de pointe via API et des modèles à poids ouverts que vous pouvez auto-héberger, et des modèles à poids ouverts sont aussi disponibles en API managée. Concrètement : une API managée (Claude, Gemini, Mistral) donne accès à la qualité de raisonnement de pointe plus tôt et maximise le time-to-value ; un modèle auto-hébergé maximise le contrôle, la souveraineté et la maîtrise des coûts au gros volume. L’écart de raisonnement entre poids fermés et poids ouverts performants se réduit d’année en année, ce qui rend l’auto-hébergement de plus en plus crédible — raison de plus pour ne pas figer le choix. La bonne architecture est souvent multi-modèles : un modèle puissant pour les tâches complexes, un modèle plus léger pour le gros du volume.
À quoi ressemble concrètement une éval ?
Les évals ne servent pas qu’au choix du modèle : ce sont elles qui valident, dès le scoring, le critère « maturité du modèle pour la tâche » de votre axe faisabilité. Concrètement, une éval est un jeu de test annoté à la main : par exemple 50 à 100 cas réels (des tickets SAV passés, avec leur bonne catégorie et la bonne priorité), sur lesquels vous mesurez une métrique d’exactitude (taux de bon classement, F1) et que vous comparez à un seuil d’acceptation métier défini à l’avance (« au moins 90 % de bon routage, sinon escalade humaine »). Un cas d’usage qu’aucun modèle ne franchit aujourd’hui est faisable « plus tard », pas « maintenant ». L’éval n’est pas un gadget de data scientist : c’est le contrat de qualité chiffré entre le métier et la technique.
Ne figez jamais le choix du LLM dans le marbre de la feuille de route : abstrayez-le derrière une couche d’orchestration. Concrètement, cette couche assure le routage multi-modèles (envoyer chaque requête au bon modèle selon la complexité et le coût), le fallback (basculer automatiquement sur un modèle de secours en cas d’indisponibilité ou d’échec), et l’observabilité (journaliser coûts, latences et qualité de chaque appel pour pouvoir arbitrer). C’est exactement ce que permet une architecture gouvernée — voir le guide N8N, MCP et agents LLM.
Pourquoi tant de plans IA ne produisent aucun ROI ?
L’écart se creuse non pas au stade de l’expérimentation, mais au passage à l’échelle. Quelques ordres de grandeur, avec leur source.
Le facteur commun des échecs n’est presque jamais le modèle. C’est l’absence de chemin clair de l’idée à la production. Les chiffres x3, 3-4 mois et 5-8 proviennent du portefeuille de missions de cadrage ianos entre 2023 et 2025. Le seul chiffre externe est une prévision Gartner émise en 2024 pour l’horizon fin 2025 : selon son communiqué « Gartner Predicts 30% of Generative AI Projects Will Be Abandoned After Proof of Concept by End of 2025 » (29 juillet 2024), at least 30% (au moins 30 %) des projets GenAI seront abandonnés après la phase de POC. Comme toute prévision, elle est à lire comme un ordre de grandeur de l’époque, pas comme une mesure constatée. Si ce sujet vous concerne, la checklist Passer un POC d’IA en production détaille les conditions à réunir.
Les pièges à éviter dans une feuille de route IA
- Prioriser par la techno, pas par la valeur. « On va faire du RAG » n’est pas un cas d’usage. Repartez toujours du problème métier et de son indicateur.
- Ignorer le coût de run. Le build est rarement le gros du coût sur trois ans : selon le volume de tokens, le run (tokens, infra, supervision, évals) peut peser autant ou bien plus. Dans l’exemple SAV ci-dessus, sur trois ans, le build (29 250 €) ne représente qu’environ 38 % du coût total face au run (3 × 15 600 = 46 800 €) — mais cette proportion dépend fortement du volume et n’a rien d’une règle universelle. Intégrez le run au ROI dès l’estimation.
- Sous-estimer les prérequis données. Un cas d’usage à forte valeur sur une donnée inaccessible ou sale n’est pas un quick win, c’est un piège. Vérifiez la faisabilité données avant de promettre une échéance.
- Oublier la gouvernance et la conformité. RGPD et AI Act ne sont pas une formalité de fin de projet. Un cas d’usage à haut risque mal cadré peut être bloqué en production. Anticipez le trust layer dès le scoring.
- Négliger la conduite du changement. Une solution adoptée à 20 % a un ROI négatif. Embarquez les utilisateurs finaux dès le cadrage et budgétez le temps de formation et d’enablement.
- Figer la feuille de route. Elle se révise tous les trimestres. Les modèles, les coûts et vos priorités bougent vite ; un plan IA annuel rigide est obsolète au T2.
Questions fréquentes
Combien de temps faut-il pour construire une feuille de route IA ?
Quelques semaines suffisent pour un premier portefeuille priorisé et défendable, pas six mois de comités. Un cadrage structuré (ateliers, scoring, matrice, estimation ROI du top 5 à 8) tient typiquement en trois à six semaines selon la taille de l’organisation.
Comment construire une matrice valeur / faisabilité pour l’IA ?
Décomposez chaque axe en sous-critères notés de 1 à 5. La valeur agrège le gain financier annualisé, l’impact stratégique, le volume et la réplicabilité. La faisabilité (« peut-on le faire ? ») agrège la disponibilité et la qualité des données, l’accès aux systèmes, la maturité du modèle validée par des évals, et le risque RGPD / AI Act. L’effort (« combien ça coûte ? ») reste un axe distinct. Croisez ensuite valeur et faisabilité : valeur haute + faisabilité haute = quick wins à lancer en premier ; valeur haute + faisabilité à construire = chantiers structurants à séquencer ; valeur basse = optionnel ou à écarter. Pondérez l’effort avec un score de priorité = (Valeur × Faisabilité) / Effort.
Comment estimer le ROI d’un cas d’usage IA avant de l’avoir construit ?
Chiffrez le gain métier annualisé (heures économisées x coût horaire, marge récupérée, erreurs évitées) face au coût complet sur trois ans : build, coût de run des LLM et de l’infra, supervision et conduite du changement. Exemple : 1 848 h économisées à 38 €/h = 70 224 € de gain, moins 29 250 € de build et 15 600 € de run = +25 374 € de ROI net dès l’année 1, point mort vers le 7e mois au régime stabilisé (un peu plus tard en réalité, le temps que l’agent monte en charge). Une fourchette assumée vaut mieux qu’une fausse précision ; affinez-la après le premier quick win.
Faut-il construire ou acheter sa solution d’IA ?
Achetez la commodité (besoins standards, non différenciants, SaaS conforme existant), construisez ou assemblez l’avantage différenciant (processus cœur de métier, données sensibles, intégration profonde au SI). Méfiez-vous des outils achetés puis lourdement personnalisés, qui cumulent les coûts de licence et de build.
Quel LLM choisir pour un projet d’entreprise ?
Le choix dépend de l’usage, pas d’un classement. Arbitrez sur quatre critères : performance mesurée par des évals sur votre tâche réelle, coût au volume (de moins d’un euro à plusieurs dizaines d’euros le million de tokens selon le modèle), confidentialité et souveraineté des données, latence (de l’ordre de la seconde en API pour une réponse courte). Distinguez le mode d’accès (API managée vs auto-hébergé) de la licence (poids fermés vs ouverts). Une architecture multi-modèles (modèle puissant pour le complexe, modèle léger pour le volume) est souvent optimale ; abstrayez le modèle derrière une couche d’orchestration (routage, fallback, observabilité) pour pouvoir en changer.
Qui doit porter la feuille de route IA : la DSI ou le métier ?
Les deux, sous arbitrage du COMEX. Le métier porte la valeur et l’adoption, la DSI porte la faisabilité, l’infra et la conformité. La feuille de route doit être co-signée par le dirigeant et le DSI : c’est la condition pour qu’elle survive aux arbitrages budgétaires de l’année.
Passez de l’expérimentation à l’IA en production
Commencez par un diagnostic court à prix fixe : maturité, cas d’usage à fort ROI, et une roadmap priorisée. Sans engagement.