Pourquoi le cadrage digital est encore plus crucial à l'ère de l'IA
L'IA a rendu le code accessible à tous. Un junior avec ChatGPT produit en 3 semaines ce qui prenait 3 mois. Le problème : il prend aussi des décisions architecturales majeures sans le savoir. La phase de cadrage n'est plus un luxe. C'est le dernier rempart.
Donatien Lefranc
Fondateur & Président, Leando
Le code est devenu une commodité. Et c'est le problème.
Il y a deux ans, écrire du code demandait de la compétence. Un développeur devait comprendre la logique, l'architecture, les contraintes techniques. La friction du code forçait la réflexion.
Aujourd'hui, n'importe qui peut demander à une IA de générer une API, un formulaire, un dashboard. Le code sort en quelques minutes. Il compile. Il passe les tests. Il a l'air de marcher.
Sauf que derrière chaque ligne générée, il y a des décisions implicites. Comment structurer les données ? Quelle entité est liée à quelle autre ? Qu'est-ce qu'un "client" dans ce contexte ? L'IA ne pose jamais ces questions. Elle répond au prompt, point. Et chaque prompt génère ses propres suppositions, indépendamment des autres.
Le résultat ? Des décisions architecturales majeures sont prises par l'IA, sans que personne ne s'en rende compte. Le code fonctionne en surface, mais les fondations sont incohérentes. Et quand tu veux faire évoluer le système, tout s'effondre.
La vraie question n'est plus "est-ce qu'on peut coder ça ?" mais "est-ce qu'on a compris ce qu'on doit coder, et pourquoi ?"
Vibe coding : la dette technique en 3 semaines au lieu de 10 ans
Le "vibe coding", c'est cette pratique où l'on développe au feeling avec l'IA. On décrit ce qu'on veut en langage naturel, l'IA génère, on itère par essais-erreurs. Ça marche pour un prototype. C'est catastrophique pour un produit.
Avant l'IA, la dette technique s'accumulait lentement. Un raccourci ici, un patch là, des conventions qui dérivent sur plusieurs années. Les équipes avaient le temps de voir venir, de corriger, de documenter.
Avec le vibe coding, cette même dette s'accumule en quelques semaines. Chaque session avec l'IA produit du code cohérent en interne mais déconnecté du reste. Les modèles de données divergent. Les règles métier se retrouvent hardcodées dans des endroits différents avec des logiques différentes. Et personne ne le voit parce que chaque morceau "marche" quand on le teste isolément.
Cas terrain : des juniors, 3 semaines, des décisions énormes
On a accompagné une entreprise où des développeurs juniors avaient travaillé 3 semaines avec des outils IA. Productifs, motivés, ils avançaient vite. Le problème ? En 3 semaines, ils avaient pris des décisions architecturales considérables, sans en avoir conscience et sans les remonter au management.
Structure de la base de données, relations entre entités, gestion des droits, logique de facturation : tout avait été décidé implicitement par les prompts successifs. Quand on a audité le code, on a découvert que le modèle de données rendait impossible l'ajout de fonctionnalités pourtant prévues dans la roadmap. Ce n'était pas de la mauvaise volonté. C'est que l'IA ne demande pas "êtes-vous sûr de vouloir structurer vos données comme ça ?"
« L'IA à aucun moment n'a poussé les développeurs à se poser les bonnes questions. N'importe quel prompt obtient une réponse en code. »
— Donatien Lefranc, fondateur de Leando
Le piège invisible
Le vibe coding donne l'illusion de vitesse. Mais les développeurs écrivent moins de lignes de code. Et chaque ligne a plus d'impact. Sans cadrage, chaque ligne porte une décision architecturale non validée.
Le modèle de données : la pierre angulaire que l'IA ignore
Si tu devais retenir une seule chose de cet article, c'est celle-ci : le modèle de données est la fondation de tout projet digital stable et maintenable. Et c'est précisément ce que l'IA ne sait pas concevoir.
L'IA génère des tables, des schémas, des migrations. Mais elle ne comprend pas ton métier. Elle ne sait pas que dans ton contexte, un "projet" peut avoir plusieurs "clients" mais qu'un "client" peut aussi être un "fournisseur" dans certains cas. Elle ne sait pas que ta logique de facturation doit évoluer chaque trimestre. Elle prend des raccourcis qui semblent raisonnables sur le moment et qui deviennent des murs quand tu veux scaler.
Un modèle de données bien conçu, c'est le résultat d'une conversation approfondie entre les développeurs, les métiers et les utilisateurs. C'est une traduction fidèle de la réalité opérationnelle en structure informatique. Et cette traduction ne peut pas être automatisée. Elle exige de la compréhension, du contexte, de l'expérience.
Sans cadrage du modèle de données
- Chaque feature crée sa propre représentation
- Les entités divergent entre les modules
- Impossible de croiser les données
- Refactoring massif à 6 mois
Avec un cadrage solide
- Un dictionnaire de données partagé
- Des relations validées par le métier
- Évolutivité intégrée dès le départ
- L'IA génère du code aligné
L'approche produit : comprendre avant de spécifier
Le cadrage digital ne se résume pas à écrire un cahier des charges de 200 pages. C'est même souvent l'inverse qui fonctionne.
On a travaillé sur un projet pour un grand groupe où le système était bloqué depuis un an et demi. L'approche classique avait été utilisée : spécifications détaillées, documents techniques, validation par comité. Le projet n'avançait pas. Trop de specs, pas assez de compréhension du terrain.
On est intervenus avec une approche produit. Au lieu de spécifier dans le vide, on a commencé par comprendre le quotidien des utilisateurs. Cartographier les processus réels, pas ceux des documents. Prototyper visuellement pour valider les hypothèses rapidement. Itérer avec les équipes terrain avant d'écrire une seule ligne de code.
Résultat : le projet a été livré en 8 mois, avec un mois d'avance sur le planning. Pas parce qu'on a codé plus vite. Parce qu'on a compris plus vite ce qu'il fallait construire. Et surtout, on n'a pas eu à revenir en arrière.
Comprendre le quotidien
Observer et interviewer les utilisateurs finaux. Comprendre leurs irritants, leurs contournements, leur réalité opérationnelle. Pas ce que le management pense qu'ils font.
Cartographier les processus
Mapper les flux réels de données et de décisions. Identifier les dépendances, les exceptions, les cas limites que personne n'a documentés.
Prototyper et valider
Créer des prototypes visuels pour tester les hypothèses avec les utilisateurs. Itérer rapidement. Prendre les décisions de conception avant le code, pas pendant.
Le vrai garde-fou : savoir quand on est prêt à développer
La question que personne ne pose, et qui devrait être obligatoire avant chaque sprint : "Est-ce qu'on est assez matures pour lancer le développement ?"
La maturité, ce n'est pas avoir tout spécifié. C'est avoir identifié et validé les fondations : le modèle de données, les entités métier clés, les règles qui sont susceptibles d'évoluer, les cas limites qui vont créer de la complexité.
L'IA ne fait pas cette évaluation. Elle ne dit jamais "attendez, vous n'avez pas assez réfléchi à ça." Elle prend le prompt et elle code. C'est à toi, à ton équipe, à ton partenaire de cadrage de poser cette question.
Les développeurs écrivent moins de lignes de code qu'avant. Mais ces lignes comptent plus. Chacune encode une décision. Si ces décisions ne sont pas guidées par une conception profonde, tu construis sur du sable.
La checklist de maturité avant développement
Cas terrain : quand la dette arrive avant la mise en production
On a rencontré une PME avec une DSI structurée. Pas une startup. Une vraie entreprise, avec des process, un budget, des équipes. Ils avaient lancé la construction d'un nouveau système avec les outils IA modernes. L'équipe avançait bien. Le management était confiant.
Au bout de 4 à 5 mois de développement, on a réalisé que le système avait déjà accumulé une dette technique massive. Pas parce que les développeurs étaient mauvais. Mais parce que personne n'avait formalisé la conception en amont. Le modèle de données avait été construit au fil des prompts. Les règles métier étaient éparpillées dans le code. L'architecture s'était construite par accumulation, pas par conception.
Le projet fonctionnait techniquement. Mais il était déjà rigide, difficile à faire évoluer, coûteux à maintenir. Et il n'était même pas encore en production.
Ce que ça révèle
L'IA ne supprime pas le besoin de conception. Elle le rend invisible. Et quand le besoin est invisible, personne ne le budgète, personne ne le planifie, personne ne le fait. Jusqu'au jour où le projet se bloque.
L'IA a démocratisé la capacité de coder. Elle n'a pas démocratisé la capacité de concevoir. La vraie compétence, dans un monde où tout le monde peut générer du code, c'est de savoir quoi construire et pourquoi. La première étape concrète : avant de lancer le prochain sprint, demandez à votre équipe de montrer le modèle de données. Si personne ne peut le faire en cinq minutes, commencez là.
Pour aller plus loin
Questions fréquentes
Non. Un cahier des charges liste des fonctionnalités. Le cadrage digital, c'est comprendre les processus métier, cartographier les flux de données, définir le modèle de données et valider les hypothèses avec les utilisateurs finaux. C'est ce qui fait qu'un projet tient dans la durée.
Passez à l'action
Tu veux cadrer ton projet avant que l'IA ne décide à ta place ?
Leando accompagne les PME et grands groupes dans leur phase de cadrage digital. Conception produit, modèle de données, architecture, validation terrain.
Discuter de mon projet