Cadrage projet IA : en quoi c'est différent d'un projet tech classique

L'intuition fausse qui circule dans les comités de direction

L'idée qui revient le plus souvent en réunion d'arbitrage, c'est que l'IA permet de sauter le cadrage. Le raisonnement parait logique : les assistants de code écrivent désormais une grande partie du logiciel, donc on irait plus vite en commençant par produire un prototype et en cadrant a posteriori sur ce qu'on a construit. C'est exactement l'inverse qui se passe sur le terrain. L'IA accélère la phase d'écriture du code, mais elle accélère dans la même proportion la création de dette technique, parce qu'elle infère des règles métier que personne n'a verbalisées.

Sur les missions d'audit qu'on mène en arrivant après un autre prestataire, le pattern revient avec régularité : trois semaines de développement vibe-codé, des décisions techniques structurantes prises sans que les développeurs eux-mêmes en aient eu conscience, et une mise en production qui devient impossible parce que la dette est déjà partout. Ce qui prenait un an avant prend trois semaines maintenant, et ça ne change rien au coût final, ça le déplace.

Ce qui reste commun à tout cadrage tech

Le squelette d'une note de cadrage ne change pas avec l'IA. On part de la situation observée sur le terrain et pas du discours qu'en font les équipes. On chiffre le coût de frottement actuel pour donner au dirigeant une base de décision. On hiérarchise les chantiers candidats par criticité business et levier rapide. On définit les indicateurs de succès qui permettront de juger l'atterrissage. Ces étapes ne sont pas négociables, et le cadrage IA s'y conforme à la lettre. Pour le détail de la structure générale, la grille de la note de cadrage projet digital s'applique sans modification.

Ce qui change, ce sont les arbitrages internes au cadrage. Quatre points spécifiquement, qui méritent qu'on les traite séparément parce qu'ils ont chacun produit leur lot de projets bloqués quand on les a sous-traités à l'IA elle-même.

Les quatre spécificités d'un cadrage IA

1. La modélisation métier devient une question de survie

Sur un projet tech classique, un modèle de données mal foutu produit du code laid mais qui finit par tourner. Sur un projet IA, un modèle métier flou produit un système qui apprend les mauvaises règles et les applique avec confiance. La différence est qualitative : l'IA n'échoue pas en plantant, elle échoue en se trompant silencieusement. Le cadrage doit donc consacrer plus de temps qu'avant à expliciter les objets métier, leurs relations, les règles qui les gouvernent. Sur un fournisseur d'énergie ETI que nous accompagnons, ces règles sont le soutirage, l'injection, les conventions Enedis, le calcul TURPE. Tant qu'elles vivent dans la tête de cinq personnes, aucun assistant de code ne peut les coder correctement.

2. Le découpage en deux phases devient obligatoire

Un projet tech classique peut s'engager directement sur l'industrialisation après cadrage parce que la performance attendue se prédit raisonnablement. Un projet IA ne le peut pas. La performance d'un modèle dépend de la qualité réelle des données, de la diversité des cas terrain, et de spécificités qu'aucune analyse a priori ne révèle complètement. Le cadrage doit donc systématiquement séparer une phase de faisabilité courte, deux à quatre semaines avec un objectif chiffré, et une phase d'industrialisation qui ne démarre qu'après validation. Sur France Coquillage, c'est ce phasage qui a permis de prouver qu'on passait de cinquante à quatre-vingt-quinze pour cent de détection avant d'engager le coût d'intégration hardware.

3. La conception devient le garde-fou principal

Avant l'IA, la qualité d'un projet se jouait beaucoup à l'exécution : revues de code, tests, refactoring continu. Avec l'IA, le code se génère trop vite pour que la revue à la ligne suive le rythme. La qualité se joue maintenant principalement à la conception. Si l'architecture, le modèle de données et les règles métier sont bons, l'IA accélère la livraison sans créer de dette. S'ils sont flous, l'IA les fige dans une base de code que personne n'ose toucher trois mois plus tard. Le cadrage IA est donc, par construction, plus exigeant sur la conception que ne l'était un cadrage classique.

« L'IA permet que le code devienne une commodité. Mais ça permet aussi d'accélérer énormément la phase de développement, et ce que ça rend opaque, c'est la dette qu'on crée. »

4. La donnée doit être auditée avant tout engagement

Sur un projet classique, l'audit de la donnée existante peut se faire pendant le développement, à condition d'avoir prévu le temps. Sur un projet IA, il doit être fait avant le cadrage du périmètre, sinon on cadre dans le vide. Les données sont-elles disponibles dans un format exploitable ? Couvrent-elles les cas terrain rares qui font la différence ? Sont-elles annotées, ou faut-il prévoir un effort dédié pour le faire ? Ces questions changent radicalement le périmètre du projet, parfois en doublant l'effort initial estimé, parfois en l'allégeant. Les ignorer en début de cadrage produit des plannings qui glissent sans qu'on sache pourquoi.

Ce que ça donne quand on sépare les deux logiques

Sur les projets IA qu'on a livrés en production, le pattern de cadrage qui marche est toujours le même : deux à quatre semaines pour modéliser les objets métier et expliciter les règles tacites, une phase de faisabilité courte avec un indicateur chiffré, puis une décision binaire d'industrialiser ou non. Sur Cartoon Prod, micro-PME du spectacle vivant, ce phasage s'est traduit par trois ateliers de cadrage suivis de deux semaines de POC en production, avec un retour sur investissement attendu sous six à sept mois. Le dirigeant a décidé sur un chiffre, pas sur une promesse, parce que le cadrage avait permis de poser ce chiffre.

À l'inverse, les projets qui arrivent chez nous en mode pompier suivent le scénario opposé. Une startup sport avait confié son application à un freelance qui a vibe-codé sur quelques semaines, sans cadrage métier, sans modélisation préalable, en s'appuyant sur les assistants pour générer le code. Le résultat : une mise en production impossible, un contrat client structurant en jeu, et une remise sur rails qui a coûté l'équivalent du temps qu'aurait pris un cadrage propre au départ. Le cas est traité en détail dans le danger du vibe coding et de la dette technique, et il revient avec une régularité préoccupante depuis dix-huit mois.

Pour un cadre plus large sur la place de la conception à l'heure où le code devient une commodité, pourquoi le cadrage digital est crucial à l'ère de l'IA propose la doctrine d'ensemble. Pour le format opérationnel d'un atelier de cadrage qui intègre ces spécificités, l'atelier de cadrage en trois semaines décrit la séquence concrète.

Si vous préparez un projet IA dans les prochains mois, deux actions concrètes valent la peine d'être prises avant de signer quoi que ce soit. La première : lister sur une page les règles métier que votre équipe applique sans les avoir jamais écrites, et identifier celles qui changent selon les cas. La seconde : vérifier auprès de votre référent data si les jeux de données utilisés dans vos processus actuels sont effectivement disponibles, exploitables, et représentatifs des cas terrain rares. Ces deux inputs déterminent à eux seuls si le cadrage IA partira sur des bases saines ou sur du sable.