La productivité augmentée par l'IA est une nouvelle discipline. Même pour les CTO.
Partie 2 de notre série sur la vélocité. Dès qu'une heure-développeur ne livre plus un point, tout ce qui repose sur cette hypothèse casse à son tour : la planification, le recrutement, la montée en compétences. Et personne n'a encore le mode d'emploi.
Jun 20, 2026
Dans Votre courbe de vélocité vous ment, nous expliquions comment l'outillage IA a brisé l'hypothèse sur laquelle repose tout outil de suivi de projet, à savoir qu'une heure-développeur livre un point de travail, et comment nous avons reconstruit le suivi de vélocité pour apprendre le vrai multiplicateur de chacun à partir de son historique.
C'était le problème de la mesure. Et c'était la partie facile.
La même hypothèse cassée se cache sous presque tout ce dont les dirigeants dépendent : la façon dont ils planifient, ce qu'ils laissent partir en production, dont ils recrutent, et dont ils développent les compétences. Tout cela casse aussi, et contrairement au suivi de vélocité, il n'existe pas de mode d'emploi établi à copier.
Et ce n'est pas seulement le problème d'un CTO. Si votre entreprise distribue un produit numérique (un logiciel, une plateforme SaaS, une application, un service automatisé), cette bascule touche votre roadmap, votre plan de recrutement et votre compte de résultat. C'est autant un sujet de PDG, de COO et de direction produit qu'un sujet d'ingénierie ; le CTO a simplement tendance à le voir en premier. Voici où l'ancienne méthode échoue, et ce qui la remplace selon nous.
Pourquoi un diagramme de Gantt ne suffit-il plus ?
Parce que la planification supposait une conversion fixe entre les personnes, le temps et la production, et que l'IA a transformé cette conversion en une variable mouvante, propre à chacun.
Pendant une décennie, le travail de planification d'un CTO relevait essentiellement de l'allocation : prendre une vélocité d'équipe à peu près stable, l'étaler sur un calendrier, ordonner les dépendances, et l'on obtenait un Gantt qui tenait lieu de prévision défendable. La partie difficile était d'ordonner le travail, pas de prédire le rythme. Et même cela n'a jamais été parfaitement maîtrisé : les équipes techniques sont réputées pour mal tenir leurs estimations, et les retards de livraison ont toujours été plus la règle que l'exception. Le modèle d'avant était déjà fragile. Mais l'unité sous-jacente à la prévision était au moins assez stable pour qu'on puisse planifier autour.
C'est désormais ce rythme qui est instable. Comme nous le détaillions dans la Partie 1, le multiplicateur diffère d'une personne à l'autre, diffère entre les petits tickets et les gros, et dérive à chaque amélioration de l'outillage. Quand un ingénieur senior pilotant des agents en parallèle livre quatre à sept points dans le temps que la courbe compte comme « une heure », un Gantt tracé sur une moyenne est faux dès le jour où on le dessine.
Le métier change donc de forme. Il ne s'agit plus d'ordonner les tâches sur une vélocité connue, mais de réallouer en continu vers l'endroit où le levier est le plus fort ce mois-ci, bien plus proche de l'allocation de portefeuille ou de capital que d'un planning de chantier. On ne gère plus un plan. On gère une distribution de levier qui bouge vite, et c'est cette distribution qu'il faut surveiller.
Et c'est réellement nouveau même pour des CTO expérimentés. Les réflexes qui faisaient leur force (estimation fiable, roadmaps régulières, intuition des délais) peuvent désormais induire activement en erreur. Il n'existe pas de vingt ans de pratique pour une réalité qui a dix-huit mois.
Quels nouveaux goulots d'étranglement cette vitesse crée-t-elle ?
Quand la production se multiplie, la contrainte se déplace en aval : vers la revue, la vérification et la décision de ce qui part réellement en production. Et l'échec devient plus subtil : l'IA produit une sortie fluide et bien argumentée qui, si elle est fausse, est souvent bien plus difficile à repérer que quelque chose qui casse visiblement.
Le goulot se déplace. Quand un développeur livre quatre à sept fois plus, la limite de l'équipe cesse d'être combien de temps pour coder une fonctionnalité et devient combien de temps pour la relire, la tester et lui faire confiance avant la mise en production. Injectez 5× le volume dans un pipeline de revue dimensionné pour 1× et vous n'avez pas supprimé la file d'attente : vous l'avez seulement déplacée. C'est précisément d'où vient l'écart de la Partie 1 entre le temps de code actif et le temps calendaire : le code est écrit en deux heures, puis attend deux jours qu'un humain se porte garant.
Les erreurs changent aussi de forme. Les anciens bugs avaient souvent la délicatesse de ressembler à des bugs : ça ne compilait pas, le test passait au rouge, la sortie était visiblement absurde. L'échec caractéristique de l'IA est l'inverse : confiant, plausible, bien expliqué, et faux. Une mauvaise réponse accompagnée d'un raisonnement convaincant est bien plus difficile à repérer qu'une réponse qui a visiblement l'air fausse, si bien que la probabilité qu'une erreur passe inaperçue augmente alors même que la productivité brute grimpe. Nous avons déjà écrit que même 98 % de précision ne suffisent pas à l'échelle : deux erreurs sur cent deviennent six cents sur trente mille.
L'implication pour les dirigeants est inconfortable : on ne peut pas simplement empocher la vitesse. Une partie de la capacité libérée par l'IA doit être réinvestie dans la vérification : des tests plus solides, des exécutions à blanc, des points de contrôle humains là où le coût de l'erreur est élevé, et une discipline de revue qui passe à l'échelle avec la production. Les équipes qui ne comptent que l'accélération, et pas la nouvelle charge de vérification qu'elle crée, livrent plus, et livrent davantage de choses discrètement fausses, découvertes plus tard.
Comment recruter pour un poste qui n'a pas encore de fiche de poste ?
On arrête de recruter sur les titres et les diplômes, parce que les rôles, le consensus et la filière de formation n'existent pas encore, et on recrute pour le jugement, la capacité d'adaptation et le levier démontré.
Regardez de près : l'échafaudage sur lequel on s'appuie d'habitude n'est pas là.
- Les rôles ne sont pas définis. Pas de titre établi, ni d'accord sur ce que fait un « ingénieur IA » par rapport à un « développeur augmenté par l'IA » ou à un profil « forward-deployed ». On ne peut pas copier une fiche de poste que le secteur n'a pas encore écrite.
- Le monde académique n'a pas suivi. Les cursus enseignent une stack qui évolue plus vite que le programme ne peut être validé. Et la vague des bootcamps vend surtout de la certitude (un certificat) sur des compétences encore en pleine formation. Il n'existe pas de formation diplômante en « orchestrer une flotte d'agents pour livrer 5× plus », parce que la chose existait à peine l'an dernier et qu'on est bien loin du consensus (en tout cas à la mi-2026).
Quand les signaux habituels (X années d'expérience, correspondance de mots-clés, un diplôme) ne mesurent plus rien de fiable, les signaux qui subsistent sont plus difficiles à simuler : le goût et le jugement (savoir ce qui mérite d'être construit, et comment vérifier ce que l'IA a produit), la vitesse à laquelle quelqu'un apprend et s'adapte réellement, et le levier concret qu'il sait déjà démontrer avec ces outils.
La même chose transforme la gestion des personnes déjà en poste. Le multiplicateur est individuel, appris et mouvant, si bien que les grilles de niveaux, de rémunération et de carrière calibrées sur des approximations de séniorité (ancienneté, story points, lignes de code) mesurent mal les gens. On finit par piloter sur la trajectoire et le levier, pas sur des approximations. Et soyons honnêtes : il n'y a pas encore de consensus. Quiconque vous vend un référentiel de compétences abouti pour l'ère de l'IA vous vend une certitude qui n'existe pas.
Quelle est la place des formations et des ateliers ?
Ils font double emploi : ils construisent la culture qui porte l'adoption, et ce sont le moyen le moins cher d'identifier les projets à fort ROI, parce que les personnes qui connaissent les workflows pénibles sont aux opérations, pas dans l'équipe IA.
Le levier de l'IA ne se diffuse pas en achetant des licences. Il se diffuse quand les gens comprennent ce qui devient possible et acquièrent le réflexe d'y recourir sur le bon problème. Un bon atelier démystifie la technologie et transforme une poignée d'utilisateurs avancés en une organisation qui maîtrise le sujet et peut porter elle-même l'adoption.
Mais le bénéfice le plus sous-estimé, c'est la découverte. Les meilleurs projets IA se situent à l'intersection de deux savoirs : ce qui est nouvellement possible techniquement (les ingénieurs le savent) et ce que font réellement les opérations toute la journée (les opérationnels le savent, et eux seuls). Réunissez les deux groupes dans une salle et cette intersection apparaît vite, classée par ROI, ancrée dans des workflows que de vraies personnes exécutent, et non dans les suppositions d'un slide de stratégie.
C'est aussi pour cela que cette approche bat un mandat IA imposé d'en haut. Quand les équipes qui utiliseront les outils participent à les choisir, elles s'approprient le résultat, et c'est l'essentiel de la bataille de l'adoption. Les projets qui en sortent sont réels, parce qu'ils sont synchronisés avec les opérations plutôt qu'imaginés au-dessus d'elles. On réduit le risque et on découvre en même temps.
Ce que tout cela signifie
La courbe de vélocité n'était que le premier instrument calibré pour un monde qui n'existe plus. Le diagramme de Gantt, la fiche de poste et le calendrier de formation sont les trois suivants.
Les dirigeants qui s'en sortiront ne seront pas ceux qui trouveront le cadre parfait : il n'en existe pas encore, et quiconque prétend le contraire devine. Ce seront ceux qui traitent la productivité augmentée par l'IA comme quelque chose à mesurer, recruter et faire monter en compétences en continu, tout en restant lucides sur le fait que le mode d'emploi s'écrit encore. L'heure a cessé d'être une constante. L'organigramme, la fiche de poste et le plan de formation sont les prochains, et le travail consiste à arrêter de coder en dur des hypothèses pour commencer à les apprendre du réel.
Reflekt Lab anime des ateliers de stratégie IA et des missions de CTO à temps partagé pour aider les équipes à naviguer exactement cela. Si votre approche de la planification, du recrutement ou de l'adoption a un train de retard, parlons-en.