Retour au blog
IA

ON N'A JAMAIS ÉTÉ AUSSI RAPIDE À ÉCHOUER SUR DE LA PRODUCTION DE VALEUR (ET C'EST UNE TRÈS BONNE NOUVELLE)

Bonne nouvelle pour tous les CODIR de France et de Navarre : vous allez enfin pouvoir écrire "on capitalise sur l'échec" dans une slide sans mentir.

Pendant des années, cette phrase ("je ne dirai pas que c'était un échec, ça n'a pas réussi") n'a été qu'un joli mensonge qu'on se raconte entre deux copil. Dans les faits, un échec coûtait du temps, et du temps, c'est de la moula. On enterrait le sujet, on renommait le JIRA, et on passait à autre chose en espérant que personne ne pose de questions. Parfois on faisait même pire : on mettant en prod les yeux plein d'espoirs en imaginant que - sur un malentendu, la feature pouvait quand même rencontrer son public (de niche).

Mais à quel prix ?

L'ancien monde carburait à l'espoir et au Gantt

Avant, tester une idée de feature ressemblait à monter un dossier de visa Schengen : PRD, specs techniques, arbitrage, ticket JIRA avec trois sous-tâches et un epic parent, deu, trois semaines, voir plusieurs mois de développement, une recette, et enfin, luxe suprême, une mise en prod. Si l'hypothèse était fausse, on le découvrait un mois plus tard, avec une équipe entière qui avait cru dur comme fer à un truc que personne n'avait jamais vraiment vérifié avant de lancer son IDE.

Le pire, c'est que ce mois-là servait rarement à apprendre quoi que ce soit. Il servait surtout à construire un alibi collectif pour la prochaine réunion : "on a suivi le process, donc ce n'est la faute de personne". Un process irréprochable, un apprentissage proche de zéro.

Le nouveau monde carbure au prompt et au café tiède

Aujourd'hui, la même hypothèse se cadre en une heure, se prototype en une soirée, et se retrouve devant un vrai utilisateur avant que le café du matin ait fini de refroidir. On n'a pas rendu les idées meilleures, hein, ne rêvons pas, on continue à sortir des fonctionnalités dont personne ne voulait, avec la même conviction sincère qu'avant. La différence, c'est le prix du ticket pour s'en rendre compte. On est passé d'un mois de certitude coûteuse à trois jours de doute bon marché.

Le droit à l'intuition

Mécaniquement, ça veut dire qu'on va échouer beaucoup plus souvent, en valeur absolue, et c'est très exactement le point. Un CTO qui compte encore ses succès en "features livrées ce trimestre" mesure une variable devenue à peu près aussi utile qu'un Minitel.

La variable qui compte, c'est le nombre d'idées fausses qu'on a réussi à tuer avant qu'elles ne coûtent un trimestre entier de roadmap et l'estime de soi de toute une squad ou de tout le pôle Product Development (oui, il faut vivre avec son temps).

Le vrai métier rare n'est plus de construire

Pendant quinze, vingt (quarante ?) ans, le facteur limitant d'une roadmap, c'était la capacité d'exécution : combien de développeurs, combien de sprints, combien de café. Ce facteur vient de s'effondrer d'un coup, sans prévenir. Ce qui reste cher, ce n'est plus d'écrire le code, c'est de savoir quel code mérite d'être écrit en premier. Le talent rare dans une équipe n'est plus "on sait le construire", vu que tout le monde sait le construire maintenant, y compris le stagiaire et son abonnement Claude Code.

Le talent rare, c'est "on sait quelle version tester cette semaine, et surtout on sait sur quel signal on aura le courage de la tuer vendredi".

Ça déplace le travail du CTO d'un cran vers l'amont. Moins de temps à sécuriser des capacités de dev, plus de temps à écrire des critères d'arrêt clairs avant même d'ouvrir l'éditeur. Un plan qui dit "si en 48h on n'a pas ce signal, on arrête, sans négociation, sans deuxième chance sentimentale" vaut objectivement plus qu'un backlog trimestriel soigneusement priorisé par ordre d'ancienneté politique.

Ce qui bloque encore, ce n'est jamais l'outil

Le vrai frein, en 2026, ce n'est presque jamais la technique. C'est la gouvernance qui a gardé les réflexes du monde d'avant : le comité stratrégique qui exige un business case en béton armé avant d'autoriser trois jours de prototype, l'équipe qui a encore honte de présenter un test qui n'a rien donné comme si c'était une faute professionnelle, la roadmap gravée dans le marbre un an à l'avance "parce que c'est comme ça qu'on fait depuis toujours et ca assure les investisseurs".

Tout ce qui retarde le moment où un prototype touche un vrai utilisateur coûte objectivement plus cher qu'avant, parce que pendant ce temps-là, quelqu'un d'autre a déjà testé, tué et enterré cinq hypothèses avec le budget d'une seule des vôtres.

Piloter une équipe tech / product aujourd'hui, ce n'est plus arbitrer entre des projets financés sur douze mois. C'est organiser un flux de petits paris qu'on encaisse ou qu'on referme en quelques jours, sans y laisser ni le moral ni le compte en banque. Le CTO qui gagne n'est pas celui qui affiche le moins d'échecs sur son CV LinkedIn. C'est celui dont l'équipe en encaisse le plus par mois, en souriant, et sans jamais refaire la même erreur deux fois.

Besoin d'aide sur ce sujet ?

Discutons de comment je peux vous accompagner.

Faire le diagnostic