On assiste à un engouement massif pour le vibe coding, cette idée que l'on peut développer une application de manière purement intuitive en discutant avec l'IA. La productivité semble là, mais qu'en est-il de la qualité ?
Didier Girard : C'est une illusion complète. Le vibe coding ne couvre qu'une infime partie du cycle de production logiciel : l'étape 3, celle du build. La qualité ne vient pas du prompt, mais du processus industriel qui l'entoure. Nos analyses internes chez SFEIR montrent que les prompts saisis par les développeurs font en moyenne moins de 100 mots. C'est une formulation sémantiquement très pauvre. On ne bâtit pas un système d'information robuste et maintenable sur une consigne aussi indigente.
« Une IA, c'est une machine à produire du code. Il faut la voir comme une machine à produire du code. Elle arrive, elle n'est pas réglée. »
La qualité est une affaire de contexte et de paramétrage, pas d'inspiration du moment. C'est la métaphore de la machine-outil : une machine parfaitement réglée produit la même pièce de haute précision, quel que soit l'opérateur qui appuie sur le bouton. L'enjeu se déplace du geste de l'artisan vers l'ingénierie du système de production.
Pour répondre à ce besoin d'encadrement, vous préconisez un nouveau cycle de vie logiciel (SDLC) spécifiquement pensé pour l'IA. Pourquoi le modèle classique ne suffit-il plus ?
Charlotte Ryssen (Coumont)
Didier Girard : Le SDLC traditionnel a été conçu historiquement pour compenser les lacunes et les biais de l'esprit humain. L'IA, elle, présente d'autres types de failles : les hallucinations, la dérive ou l'incohérence architecturale. Il nous faut donc un cadre méthodologique taillé pour ses spécificités. C'est ce que formalise notre framework en 11 étapes, publié initialement le 16 juin, et qui capitalise sur les projets réels que nous menons en interne depuis notre accès à Claude Code en février 2025.
Plaintext
[0. Setup] -> [1. Define]* -> [2. Plan]* -> [3. Build] -> [4. Verify] -> [5. Review]
|
[10. Retrait] <- [9. Learn Dyn.] <- [8. Monitor] <- [7. Ship]* <- [6. Compound / Learn Stat]
* Les seuls pivots stratégiques où l'intervention humaine reste requise.
Dans notre cible industrielle, l'humain doit s'effacer des tâches d'exécution pure. « La cible, c'est que l'humain ne soit présent plus que dans les phases 1, 2 et 7 » (Define, Plan, Ship). Tout le reste s'automatise via deux boucles de rétroaction majeures : le compound (apprentissage statique qui sédimente la connaissance dans les dépôts de code) et la télémétrie en production (apprentissage dynamique à l'étape 9 jusqu'au retrait du code à l'étape 10). Enfin, ce modèle n'est pas universel ; il exige des briques spécialisées par technologie. On ne traite pas du legacy COBOL comme on pilote des microservices Java ou du développement mobile.
Une telle automatisation implique une consommation massive de puissance de calcul. Comment un DSI doit-il appréhender l'évolution de ces coûts ?
Didier Girard : C'est un point de bascule économique majeur, accéléré par l'arrivée récente des modèles de raisonnement avancés. Avant le déploiement de la lignée Fable, j'estimais qu'il fallait budgétiser environ 10 € par heure et par ingénieur en consommation d'IA. Avec des modèles comme Fable, nous sommes passés à environ 100 € de consommation par heure. L'inflation est brutale.
« Un DSI doit impérativement inscrire dans son budget une ligne token. »
Piloter une direction technique aujourd'hui sans cette prévision, c'est comme manager une flotte de taxis en oubliant de prévoir une ligne budgétaire pour l'essence. Pour ne pas exploser ses coûts, l'entreprise doit mettre en place un pilotage FinOps token et orchestrer le choix de ses modèles par phase :
- Les modèles d'élite (type Fable) : Réservés exclusivement aux phases à haute valeur conceptuelle comme le Plan ou la Review.
- Les modèles polyvalents (type Opus) : Alloués aux phases de Define et de Build.
- Les modèles légers (type Sonnet, Haiku) : Déployés sur les tâches de flux continu comme la vérification (Verify), le déploiement (Ship) ou la supervision (Monitor).
Il est également crucial de s'émanciper des monopoles occidentaux en évaluant des alternatives en code ouvert. Par exemple, le modèle asiatique GLM 5.2 de Z.AI offre des performances proches du niveau d'un Opus 4.8 sur le traitement textuel strict, pour un coût opératoire nettement inférieur.
Charlotte Ryssen (Coumont)
À maturité, d'ici 4 à 5 ans comme le soulignait Arthur Mensch lors de son audition à l'Assemblée nationale, le budget tokens représentera facilement 10 % de la masse salariale globale d'une direction technique.
Charlotte Ryssen (Coumont)
Cette automatisation transforme radicalement le quotidien des ingénieurs. Comment l'organisation doit-elle absorber ce choc culturel ?
Didier Girard : Il y aura de la résistance et c'est normal. C'est une réaction humaine légitime face à un changement de paradigme. Mais fermer les yeux ou interdire l'usage de ces outils est une impasse. J'utilise souvent la métaphore du grand-père et de la tronçonneuse : l'apparition de la machine n'a pas tué le métier de bûcheron, elle a profondément transformé son geste technique et sa productivité.
Le marché a basculé très vite. Le véritable point d'inflexion s'est produit entre décembre et janvier avec l'arrivée d'Opus 4.5/4.6 : c'est le moment précis où l'IA a commencé à produire un code de qualité supérieure à celui d'un ingénieur. L'ingénieur logiciel devient celui qui règle la machine. On attend de lui une compréhension systémique de l'architecture globale plutôt qu'une finesse d'écriture locale. Cette standardisation par le SDLC va d'ailleurs permettre à des profils plus juniors, ou même à des Product Owners, de corriger eux-mêmes des anomalies simples en production.
« Une personne avec de l'IA sera aussi productive que cinq personnes travaillant de manière traditionnelle. »
Cette démultiplication de la performance signe la fin des structures élargies. La fameuse two-pizza team théorisée par Jeff Bezos s'efface désormais au profit de micro-équipes chirurgicales de 1 à 2 personnes par projet : une véritable sandwich team !
Quel est le principal piège de gouvernance pour une entreprise qui se lance dans cette transition à grande échelle ?
Didier Girard : Le risque majeur est de laisser une démarche purement organique s'installer, ce qui conduirait à l'émergence d'un SDLC différent par projet en fonction des affinités de chaque équipe. C'est le chemin le plus court vers l'anarchie technique.
Le déploiement doit être résolument descendant (top-down). Il faut structurer une entité centrale, un Center for Enablement (CoE), chargée de définir la doctrine méthodologique et de piloter les arbitrages FinOps. Pour éviter l'effet "tour d'ivoire", ce centre doit s'appuyer sur des AI Champions issus du terrain. Dans notre propre organisation chez SFEIR, nous avons identifié précisément environ 60 champions (soit 10 % de nos forces d'ingénierie), et environ 20 d'entre eux se consacrent exclusivement et à plein temps à l'évolution constante de notre framework.
Au-delà des outils, le véritable défi se situe dans la conduite du changement au sommet des organisations. Comme j'aime à le rappeler :
le succès appartiendra aux entreprises capables de mener cette acculturation à l'échelle globale. L'enjeu n'est pas technique, il est culturel.
SFEIR
