Sauf que des principes clairs, ça ne fait pas une usine qui tourne. Entre l’idée et la première version qui a vraiment livré du code, il y a eu plusieurs tentatives, quelques impasses et un redémarrage complet. Si vous avez déjà lancé un chantier d’automatisation qui a commencé par ralentir l’ensemble en ajoutant de la complexité au lieu d’en retirer, cette histoire va vous parler.

De la théorie à la pratique

Au printemps, on avait nos principes, des idées plein la tête, et une méthode encore purement théorique. Nous avons alors construit notre première usine depuis ce canevas purement théorique, et on l’a lancée.

A son démarrage, on a vu des choses bouger, on s’est dit que ça allait marcher. Puis on a essayé de s’en servir.

Ce qui a cassé

Trois choses. D’abord, chaque poste produisait son propre compte-rendu pour le suivant, et un humain devait valider à chaque étape. Résultat : une file d’étapes de validation, exactement ce qu’on cherchait à supprimer. Ensuite, le cadre était si serré que la machine demandait la permission pour tout, y compris pour agir sur l’usine elle-même. « Je ne peux pas modifier ce fichier. Celui-là non plus. Tu m’autorises ? » Dix allers-retours pour une étape. On avait construit quelque chose de plus rigide que de travailler à la main avec l’IA. Enfin, la verbosité. La machine expliquait tellement de choses qu’à la fin, on ne comprenait plus ce qui ne marchait pas.

On a même donné l’outil à un collègue sur un autre projet. Il n’a rien compris à ce que l’usine avait produit. Et quand il nous l’a montré, on n’a rien compris non plus : un mélange du vocabulaire de notre méthode, qu’il ne connaissait pas, et du vocabulaire de son métier, qu’on ne connaissait pas. Personne ne pouvait lire ce que l’usine avait écrit.

Quatre jours à régler la machine et pas une ligne de code livrée.

Repartir de zéro

Le jour suivant, on a tout mis de côté et on est repartis d’une page blanche. Avec une conviction en plus : on ne peut pas concevoir un système parfait sur le papier. Les vrais problèmes n’apparaissent qu’une fois que ça tourne. Il faut donc lancer une version simple, la faire travailler sur un vrai projet, corriger ce qui bloque, relancer, et recommencer.

Cette fois, pas de programme magique. On a décrit précisément ce dont on avait besoin, et on a construit l’usine une brique à la fois, en lançant chaque poste à la main pour vérifier qu’il faisait bien son travail avant d’ajouter le suivant. Ça n’avançait pas aussi vite que souhaité, mais ça livrait du code.

Puis les réglages sont venus les uns après les autres. On a supprimé les comptes-rendus entre chaque poste au profit d’un seul fil qui suit le travail d’un bout à l’autre. On a automatisé progressivement, un poste après l’autre, au rythme où la confiance montait. On a donné à chaque poste des consignes courtes, propres à sa mission. Et enfin, on a imposé une règle de sobriété à la machine : deux ou trois phrases pour dire ce qu’elle a fait, le détail seulement si on le demande.

La leçon, on la connaissait déjà sans l’avoir vécue. Quand on ne fait pas confiance à un système, on lui ajoute des validations. Et on recrée exactement la lourdeur qu’on voulait supprimer. La confiance ne vient pas du contrôle, elle vient d’autre chose : savoir ce qui se passe dedans.

L’heureux hasard

Tous ces réglages, on les a faits en réaction : quelque chose bloquait, on corrigeait. Mais le changement qui a le plus fait progresser l’usine est venu par hasard. À la fin de chaque lot, on avait pris l’habitude de demander à la machine un court bilan : ce qui s’était bien passé, ce qui avait coincé, où elle avait perdu du temps. Au départ, c’était juste pour garder une trace et s’en souvenir plus tard.

Très vite, ce bilan est devenu le point de départ de chaque nouveau lot. On le lisait, on repérait les deux ou trois choses à corriger, on ajustait l’usine, et on relançait. Sans l’avoir cherché, on tenait notre troisième principe : l’amélioration continue fonctionne comme une chaîne, avec ses étapes et son rythme. L’usine ne s’est pas améliorée parce qu’on la surveillait de près. Elle s’est améliorée parce qu’on lui demandait, à chaque tour, ce qu’il fallait changer.

De ce premier échec, on a gardé une règle simple.
Il y a ce qu’on ne touche pas : les principes.
Il y a ce qu’on règle selon le contexte : les postes, les consignes, le niveau d’automatisation.
Et il y a ce qui appartient à chaque projet : ses choix propres.

Notre erreur avait été de vouloir tout figer d’avance, y compris les deux derniers. Pour votre équipe, la question à poser avant un chantier de ce type n’est donc pas « est-ce que ça marchera partout », mais « est-ce qu’on saura voir où ça coince ».

On en a fait un livre

Au bout de quelques mois, on s’est rendu compte d’une chose : ce qu’on venait de vivre, personne ne le racontait. Les articles parlaient des outils, jamais de ce qu’il faut monter dans une équipe pour qu’ils servent à quelque chose. Les échecs, on ne les trouvait nulle part.

Alors on a décidé de tout écrire.

Dix mois de construction, d’impasses et de réglages. Plusieurs CTOs qui ont accepté de raconter les leurs, sans arrondir les angles. Et une méthode complète pour monter une usine logicielle dans une équipe qui existe déjà, avec son code, ses habitudes et ses contraintes. Ce n’est pas un guide de plus pour bien utiliser l’IA. C’est un livre sur ce que ça change, pour une équipe et pour une entreprise, le jour où plus personne n’écrit le code à la main.

Il sort le 26 novembre.

Et dans la prochaine édition, je vous raconte comment il est né, parce que lui non plus ne devait pas exister sous cette forme.

A très vite,

L’équipe Hones

Si vous avez équipé vos développeurs d’une licence Claude ou GPT il y a six mois, vous vous êtes peut-être posé la même question que nous : qu’est-ce que ça a changé, au fond, dans la façon dont l’équipe produit ? Souvent, pas grand-chose. C’est de cette question que notre usine est née, et on ouvre ici une série pour raconter comment on l’a construite, avec les choix, les détours et ce que ça a changé pour nous.

Chacun sa tambouille

En février dernier, on a réuni toute l’équipe une journée pour mettre à plat nos façons de travailler avec l’IA. Le constat a été rapide : mêmes besoins, mêmes problèmes, mais autant de manières de s’y prendre que de personnes autour de la table.

On avait pourtant une méthode commune, le Spec-Driven Development : écrire précisément ce qu’on attend avant de laisser l’IA produire le code, puis vérifier que le résultat correspond. Elle fonctionne très bien seul sur un projet. Mais elle finit par devenir ingérable, parce qu’elle demande à un humain de valider chaque étape, et qu’il finit par dire oui sans regarder. Et on ne parle même pas de travailler en équipe dessus…

Au même moment, nos clients nous posaient tous la même question : comment mettre de l’IA dans nos équipes de développement ? Ils avaient déjà compris qu’une licence par développeur ne suffit pas. Tout ce qu’on voyait sur le marché répondait à la question individuelle : comment devenir un bon utilisateur de l’outil. Personne ne répondait à la question d’organisation : comment on produit du logiciel quand une machine écrit le code.

C’est de là que vient notre usine.

L’usine répond à la question de la confiance. Si le code est écrit par une machine, comment je fais confiance à ce qu’elle produit ? Parce que si ça casse chez un client, ce n’est pas la machine qu’on vient voir, c’est nous. On a d’abord essayé de tout relire. Mais la machine va tellement plus vite que nous qu’on finit spectateur de son propre chantier, à vérifier au lieu de construire. Notre objectif était de créer un système qui produit du logiciel qu’on peut reprendre et entretenir, sans devoir en contrôler chaque ligne.

Ce qu’on voulait était clair. Comment y arriver, beaucoup moins. On a donc commencé par se mettre d’accord sur quelques règles, simples à énoncer, difficiles à tenir, qui allaient guider chaque décision de construction. Elles sont toujours là aujourd’hui, et elles définissent les fondations de notre usine.

Trois principes.

1. L’humain cadre et décide, la machine produit.

Une chaîne fabrique, une autre contrôle. L’humain intervient là où son jugement compte, pour définir le besoin et trancher au moment de mettre en production, pas pour cocher des cases.

2. On ne compose que du découpé.

Une usine est faite de postes distincts, chacun avec une mission claire et un résultat attendu, qu’on peut remplacer sans toucher aux autres. C’est un vieux principe d’ingénierie logicielle, celui de la clean architecture : des briques indépendantes, reliées par des contrats stables. Comme une prise électrique : peu importe ce qu’on branche, la forme ne change pas et le courant passe.

3. L’amélioration continue est elle-même une chaîne.

Après chaque lot livré, on regarde ce qui a coincé, on corrige, on garde une trace. Une usine saine n’est pas une usine sans défaut. C’est une usine où, pour chaque défaut, on sait quel poste l’a laissé passer et quoi régler pour qu’il ne revienne pas.

Ce que ça a vraiment changé dans nos pratiques.

Le changement majeur porte sur le rôle du développeur lui-même. Notre équipe ne produit plus le code : elle conçoit et règle l’outil qui produit le code, et elle porte la vision de ce qu’on veut obtenir. Le code lui-même n’est plus la partie précieuse, la machine peut le régénérer à volonté pour presque rien. Ce qui a de la valeur, c’est tout ce qui rend cette régénération possible : les consignes, les contrôles, la connaissance du métier qu’on a mis dans l’usine. C’est ça qu’on construit et qu’on entretient désormais.

Ça change aussi où on met son attention. Avant, un développeur passait une bonne partie de son temps à trancher des questions techniques en cours de route : comment structurer telle partie, quelle approche retenir pour tel besoin. Dans l’usine, c’est la machine qui instruit ces questions. Elle analyse le besoin, propose plusieurs options argumentées et en recommande une. Et à force de relire ces recommandations, on a constaté quelque chose : dans 97 % des cas, on retient celle qu’elle propose. Autant lui laisser la main sur ces choix, et garder notre temps et notre jugement pour les 3 % qui méritent vraiment qu’un humain tranche.

Pour une direction, la question n’est donc plus d’équiper les développeurs. C’est de décider à quoi ressemble la production quand ils n’écrivent plus le code.

Cette usine ne s’est pas montée d’un coup. Il y a eu plusieurs versions, plusieurs modèles abandonnés en route, et une bonne dose de fausses pistes avant d’arriver à quelque chose qui tourne pour de vrai. Dans la prochaine édition, je vous raconte l’une de ces étapes : celle où on a voulu aller trop vite, et où tout s’est effondré.

A très vite,

L’équipe Hones

« Le code généré par l’IA, c’est de la dette technique qu’on découvre six mois plus tard. »

Cette phrase vous avez dû la lire plus d’une fois cette année. C’est le genre de discours qu’on croise partout sur Linkedin; qui explique que coder avec l’IA est une mauvaise idée. Que ça produit du code fragile, impossible à reprendre, et que les boîtes qui s’y sont jetées paieront l’addition dans deux ans.

Cela va sûrement vous étonner, mais pour une fois, je ne vais pas les contredire (en tout cas, pas entièrement 😉).

On défend l’IA dans le développement depuis le début, on en a fait notre sujet, et ceux qui nous suivent savent qu’on est plutôt du genre à démonter ce genre d’argument. Sauf que sur le constat cette fois, on accepte de donner quelques points aux septiques (profitez-en, ce n’est pas le cas tous les jours).

Des bases de code qui grossissent beaucoup plus vite qu’avant, des modules dont plus personne ne sait dire pourquoi ils existent, des tests au vert qui ne rassurent plus grand monde : tout ça est bien réel, on le voit chez nos clients.

Ce sur quoi on diverge, c’est la conclusion qu’ils en tirent !

Ce qui s’est vraiment passé dans les équipes

Ces deux dernières années la plupart des boîtes ont acheté des licences de LLM à leur équipes; Copilot, Cursor, Claude code, distribués aux développeurs, en attendant de voir un miracle se produire. C’est comme ça que la plupart des IA nous ont été vendues, mais c’est ce qui a amené à la situation qu’on observe aujourd’hui.

Parce qu’un assistant IA, sans règle autour, aussi efficace soit-il, ne permettra au développeur que de multiplier son travail. Un bon développeur produira beaucoup de bon code. Une équipe qui n’avait déjà pas l’habitude de travailler ensemble produira beaucoup de code, tout court.

Dans les deux cas, la capacité de production explose et rien n’a été ajouté pour la contrôler. Le jour où quelque chose casse, personne ne peut dire d’où ça vient. L’humain ? Le modèle ? La consigne ? Le contexte qu’on lui a fourni ? Tout porte le même nom, « l’IA », et on ne peut pas débugger ce qu’on ne peut pas ouvrir.

Les sceptiques regardent ce résultat et en déduisent que l’IA ne sait pas produire du bon code. Moi j’y vois autre chose : on a demandé à des outils de faire le travail d’une organisation. Et ça ne marche jamais, avec ou sans IA.

Bienvenue à l’ère des usines IA !

Quand je dis « organisation », je ne parle pas d’un organigramme. Je parle de choses très concrètes : qui décide de ce qu’on construit, qui vérifie que ce qui sort correspond à ce qu’on a demandé, et comment on remonte à la source quand ça ne correspond pas. Dans une équipe de développeurs classique, tout ça existe déjà, souvent sans être écrit. Avec des agents IA, c’est différent.

Ce qu’il faut donc construire autour, c’est une structure où la production est découpée, où chaque étape est vérifiée, et où une erreur peut être localisée. Ce n’est pas nouveau. C’est exactement ce qu’a fait l’industrie il y a quelques décennies.

Une usine, ça s’organise autrement qu’un atelier où chacun a sa perceuse. La production est découpée en postes. Chaque poste a un rôle, une entrée, une sortie, et un contrôle avant de passer au suivant. Quand une pièce sort défectueuse, on remonte la ligne jusqu’au poste concerné, et on ne touche à rien d’autre.

Appliqué au logiciel, cela donne des agents IA spécialisés qui se passent le travail comme des postes sur une chaîne, avec une ligne de contrôle qui vérifie chaque étape avant la suivante, et des humains qui cadrent au départ et supervisent à l’arrivée.

Ce que ça change dans l’approche : le rôle du développeur n’est plus d’écrire ou de relire le code (ça n’a d’ailleurs jamais été le but du métier). Désormais, il cadre ce qu’il faut produire, décide, et contrôle la machine. Et quand la sortie pose problème, il peut désormais se demander « à quel poste ça s’est joué », et cette question a une réponse. Un composant avec un rôle défini, c’est un composant qu’on peut examiner.

Vous voyez l’écart avec la simple distribution de licences. Donner un assistant à chaque développeur, c’est faire le pari que la qualité viendra de chaque individu, multipliée par un outil. L’usine fait le pari inverse : la qualité vient de la structure, et l’individu n’a plus à la porter seul. C’est ce qui rend le résultat prévisible, et c’est aussi ce qui rend la bascule difficile, parce qu’il faut accepter de réorganiser complètement la façon dont l’équipe travaille.

Ce changement, certains l’ont déjà mis en place.

Ceux qui construisent déjà leur usine

L’industrialisation de la tech, n’est pas une idée qu’on défend dans notre coin en attendant que le marché nous rejoigne. Plusieurs entreprises en Europe, ont déjà commencé leur transformation.

Prenez Cdiscount. En juillet, ils ont présenté ce qu’ils appellent leur « usine agentique ».

Thomas Métivier et son DSI Christophe Samson étaient déjà des utilisateurs aguerris de Copilot et de Claude. Ils sont allés un cran plus loin : plusieurs agents spécialisés qui se passent le travail comme les postes d’une chaîne, l’un sur les API, un autre sur les modèles de données, un troisième sur l’interface, un dernier qui vérifie la qualité du code avant la mise en production.

Leur raisonnement est celui d’un industriel : un modèle unique se perd sur une base de code trop grande, alors on découpe la tâche en postes dédiés, pour obtenir des développements plus rapides et surtout plus fiables. L’usine tourne depuis trois mois avec quelques équipes pilotes. Elle a déjà produit plus de 80 évolutions sur le site, et l’équipe qui gère les commandes de la marketplace a ramené certaines opérations de maintenance d’une journée à environ deux heures. Métivier a fixé le cap : d’ici la fin de l’année, la moitié du code qui structure la plateforme devra sortir de ces usines.

Ce qui rend le cas intéressant, c’est d’où ils partent. Peaksys, leur filiale tech, ce sont plus de 450 développeurs à Bordeaux et une mise en production toutes les sept minutes, avec des indicateurs de vitesse et de fiabilité suivis depuis des années. L’usine agentique n’est pas venue réparer une organisation qui n’y arrivait pas. Elle prolonge une équipe qui savait déjà produire proprement, et Cdiscount le dit lui-même : ce qu’ils cherchent avec cette usine, c’est faire évoluer leur organisation en profondeur.

Et puis il y a Eno, qui part de zéro. Deux ingénieurs bruxellois, une boîte créée en janvier, et Thibaud Elzière qui en fait la première recrue de sa verticale « AI for Work » chez Hexa. Eux sont partis directement sur ce modèle. Une plateforme de briques, formulaires, tableaux, automatisations, génération de documents, connectées à des agents IA, et à partir de ça ils sortent un logiciel de gestion complet pour un métier donné. Ils ont commencé par les traiteurs, après avoir rencontré plus de 160 professionnels et travaillé avec une vingtaine de design partners. Ils visent aujourd’hui plus de 130 métiers, et ils proposent même à des entrepreneurs de venir lancer la leur sur la plateforme en apportant leur connaissance du terrain. Le logiciel n’est plus quelque chose qu’on développe une fois pour un client. C’est ce qui sort de la ligne, métier après métier.

Un géant du e-commerce qui avait déjà industrialisé son delivery, une startup qui n’a jamais connu autre chose. Deux histoires opposées, mais la même conclusion sur la façon de produire du logiciel avec l’IA. Quand des acteurs aussi différents arrivent au même endroit en même temps, on n’est plus dans l’opinion. C’est une révolution qui déjà a commencée.

Un an d’usine, ce qu’on peut déjà vous dire

Chez Hones, cela fait déjà près d’un an que nous travaillons sur le sujet. Nous avons créé notre usine AI et la faisons tourner depuis plusieurs mois.

Concrètement à quoi cela ressemble ? Un premier agent écrit la spécification, un deuxième en tire l’architecture, et l’implémentation ne démarre qu’après. En face, une ligne de contrôle séparée : des vérifications automatiques qui arrêtent tout au premier défaut, puis une relecture par un agent qui n’a pas écrit le code. La revue humaine vient en dernier et se concentre sur ce qui peut vraiment faire mal, les accès et les données personnelles notamment. Et entre chaque poste circule un document spécifique de cadrage.

Est-ce que ça règle la dette technique ? Pas entièrement, et je me méfie de ceux qui vous promettent le contraire. L’usine peut toujours faire des erreurs quand le besoin change en cours de route, et elle ne se règle pas toute seule. Mais la dette qu’elle produit, on sait où elle se trouve. Et c’est toute la différence avec ce que décrivent les septiques de Linkedin.

Il vous reste donc un choix à faire (et pas beaucoup de temps pour passer le cap) : continuer à distribuer des licences, ou réorganiser votre équipe autour. Si vous êtes dans le premier cas et que vous pensez que ça marche, répondez à ce mail et racontez-moi. Je serais sincèrement curieux de lire un contre-exemple.

Dans le prochain numéro de TechRadar, on vous ouvre le capot de notre usine : comment on l’a construite, ce qu’on a raté en route, et ce qu’on referait autrement.

A très vite,

L’équipe Hones

Dix ans plus tard, Geev c’est 7 millions de comptes créés, 3 millions d’utilisateurs actifs par an, plus de 55 millions d’objets donnés, et une boîte bordelaise de 15 personnes qui partage le portefeuille d’un fonds avec Backmarket, Swile et Shine.

Entre les deux, à peu près toutes les épreuves qu’un entrepreneur peut traverser. :

• un modèle publicitaire qui s’effondre au moment exact du lancement

• des dizaines de pistes de revenus testées pour n’en garder que quatre

• des utilisateurs qui se mettent littéralement “en grève” dans l’app après un changement mal annoncé

• et le pire moment en dix ans de boîte : perdre son CTO du jour au lendemain. Un choc humain avant tout, pour toute l’équipe, et la nécessité de continuer à gérer sans que le business n’en soit impacté.

Dans ce deuxième épisode de “De vive voix”, Hakim raconte à Joachim ce que dix ans de C2C lui ont appris : pourquoi un produit n’est pas une œuvre d’art, pourquoi il faut regarder ce que font les utilisateurs plutôt qu’écouter ce qu’ils disent et ce que coûte réellement un actif tech qu’on croit “fini”.

Une conversation sans filtre sur la résilience, les arbitrages permanents, et ce qui fait qu’une crise majeure peut ne jamais impacter votre business.

▶️ L’épisode est aussi disponible sur YouTube

Pour nous retrouver :

• Hakim Baka - CEO et co-fondateur de Geev : https://www.linkedin.com/in/hakimbaka/

• Joachim Fourquet - CEO et co-fondateur d’Hones : https://www.linkedin.com/in/joachim-fourquet-48b5a37/

👋 Bonjour,

On vous avait quittés fin juillet sur une promesse : celle de vous raconter l’histoire d’une équipe de 50 personnes qui construit, de son plein gré, le système qui la ramènera à 20.

Vous avez peut-être passé l’été avec cette question en tête. Matthieu, lui, l’a posée directement aux intéressés, dans leurs locaux.

Pour ce dernier épisode du carnet de Singapour, on quitte les rues climatisées et on entre directement dans les bureaux (climatisés) de deux scale-ups locales.

Des organisations rencontrées sur place, deux m’ont marqué plus que les autres. Une scale-up dans la santé, une scale-up fintech. Toutes deux automatisent leur développement logiciel avec l’IA, au même degré d’ambition, mais avec deux trajectoires complètements opposées.

C’est ce contraste que voulais vous raconter.

Quand 50 personnes construisent le système qui les ramènera à 20

Commençons par la santé. L’équipe technique compte 50 personnes. L’objectif, affiché et assumé par la direction : être 20 à la fin de l’année. Et le plus déroutant, c’est que le système d’automatisation qui rendra cela possible, c’est l’équipe qui le construit elle-même.

Ma première question a été la même que la vôtre : pourquoi acceptent-ils de construire un système voué à les remplacer ?

La réponse tient en un mot : le capital.

Les membres de l’équipe sont intéressés à la valorisation de la société. Si l’automatisation rend l’entreprise plus rapide et moins chère, la valorisation monte, et ils gagnent en tant qu’actionnaires ce que l’effectif perd en postes. On peut trouver le calcul cynique ou lucide, mais il a au moins un mérite : il aligne réellement les intérêts, là où beaucoup de transformations reposent uniquement sur de la communication interne.

Deuxième surprise : la vitesse. Le projet a démarré deux mois avant mon passage. En deux mois, l’organisation a pivoté sa manière de produire. Sans big bang pour autant : ils automatisent par itérations, avec beaucoup d’humains dans la boucle au départ, puis retirent l’humain à mesure que le système fait ses preuves.

Quand développer ne coûte presque plus rien, le sujet se déplace

Ce que j’ai trouvé le plus riche chez eux dépasse la question de l’effectif. Ils ont compris qu’en effaçant la complexité technique, on change la nature du risque. On ne risque plus de développer trop lentement. On risque de développer n’importe quoi, puisque plus rien ne freine.

Chaque fonctionnalité doit définir ses métriques business avant d’être développée. Après la mise en production, le suivi est entièrement automatique. Les indicateurs tombent directement dans la boîte mail du responsable métier qui a demandé la fonctionnalité. Il n’a rien à aller chercher. Il devient comptable de son choix. Et si, au bout d’un an, la fonctionnalité n’a pas prouvé son intérêt business, elle est supprimée.

Relisez cette dernière phrase. Combien d’organisations que vous connaissez suppriment des fonctionnalités qui ne servent pas le business ?

Même technologie, stratégie inverse

La 2e scale-up que j’ai rencontrée, celle de la finance, utilise les mêmes outils et le même effacement de la complexité technique, avec les équipes métier en donneurs d’ordre directs.

Mais de leur côté, aucun plan de réduction d’effectif.

Leur équation est autre : ils sont numéro 2 sur leur marché, derrière un numéro 1 bien installé. L’automatisation leur sert à produire plus et plus vite, pour attaquer cette position et viser l’international.

Un même levier qui sert donc deux direction diamétralement opposée.

C’est la leçon que je retiens du diptyque. L’automatisation ne décide de rien : elle multiplie ce que la direction a choisi. Réduire les coûts ou conquérir un marché, le système exécute l’un aussi bien que l’autre. La vraie décision reste, comme toujours, entre les mains du dirigeant.

Ce que je n’ai pas vu (et qu’on vous vendra quand même)

Un mot d’honnêteté, parce que le sujet IA en manque souvent.

Nulle part, y compris chez les plus avancés, je n’ai vu d’usine logicielle qui s’améliore toute seule, avec des agents autonomes qui travaillent la nuit. Partout, le code passe par des revues, automatiques puis humaines, avant la production. Le système est amélioré par l’expertise humaine, pas encore de son plein gré.

Si on vous vend des boucles d’auto-amélioration clés en main, vous saurez quoi en penser.

Le voyage prend fin, mais pas la conversation

Le carnet de voyage s’arrête ici. Dès la rentrée, TechRadar reprend son format habituel, toujours pour traduire les enjeux tech en business.

Un dernier mot avant de refermer ce carnet. Rien de tout cela n’aurait été possible sans les personnes qui m’ont ouvert leurs portes et accordé de leur temps sur place. Un grand merci à Sébastien, Martin, Laetitia, Marie-Pauline, Louis, Romain, Xavier, Damien, Simon, Sylvain et Frédéric pour la franchise de nos échanges. On ne raconte bien que ce qu’on nous a laissé voir de près.

D’ici là, une question à emporter dans votre fin d’été : si développer ne coûtait presque plus rien chez vous, sauriez-vous dire ce qui mérite d’être développé ?

PS : ce carnet gagne à circuler. Si un dirigeant de votre entourage se demande encore ce que l’IA change vraiment à une équipe tech, transférez-lui cet épisode ;)

Partager

👋 Bonjour,

TechRadar prend ses quartiers d’été. Pour cette édition et la prochaine, on laisse la veille de côté : Matthieu, CTO et co-fondateur d’Hones, prend la plume, carnet de voyage en main, pour raconter ce qu’il est allé voir à Singapour.

Un format plus léger pour la saison, mais pas moins nourrissant pour autant 😉

J’ai passé une semaine à Singapour début juillet. Pas pour les gratte-ciels, ni pour la baie (bon ok un peu quand même) : je voulais voir de mes yeux un écosystème tech qui a terminé sa bascule vers l’IA, pendant qu’en France nous débattons encore de son utilité dans nos équipes.

Pourquoi Singapour ? Le gouvernement y a décrété que l’IA est priorité nationale, avec des moyens à la hauteur du discours. Et c’est un territoire à cheval entre l’Asie et l’Occident, donc lisible pour un regard français.

Ce premier épisode raconte le pays. Le prochain, fin août, entrera dans les entreprises que j’ai rencontrées.

Vous verrez, le détour par ce pays n’est pas du tourisme : c’est une plongée dans la culture et le mindset local qui explique tout le reste.

Le débat que personne n’a plus

Une chose m’a frappé dès les premiers échanges avec des dirigeants sur place. La question qui occupe nos comités de direction [faut-il mettre de l’IA dans le développement ?], a tout simplement disparu des conversations. Tout le monde y est. Il sont déjà passés à l’étape d’après, les questions d’organisation : qui décide quoi, comment on priorise, ce que deviennent les métiers.

Et tout ce que je raconte dans cet épisode, l’urbanisme, les règles, même la climatisation, éclaire la même chose : comment ce pays a fait pour clore le débat plus vite que nous ?

Un territoire géré comme un produit

Singapour a absorbé un triplement de sa population en soixante ans sans saturer. La méthode, tout dirigeant tech la reconnaîtra : une vision d’urbanisme à 30 ans, stable, déclinée en jalons à 10 ans, et réajustée tous les 5 ans selon les conditions réelles. La vision ne bouge pas, la tactique si.

Remplacez « territoire » par « produit » et vous obtenez une roadmap bien tenue : un cap long qui donne la stabilité, des arbitrages courts qui absorbent le réel. Beaucoup d’organisations tiennent l’un ou l’autre, mais rarement les deux.

Même la végétation est gérée ainsi : toute construction nouvelle doit être compensée par de la végétalisation. C’est la loi. Une règle d’architecture, au sens propre.

Je m’abstiendrai de toute comparaison avec le Grand Paris. Vous la ferez très bien vous-mêmes.

Le pays qui a climatisé sa productivité

J’ai raconté sur LinkedIn le choc thermique de l’arrivée : 17 degrés à l’intérieur, un pays entier climatisé depuis les années 60 sur décision de son fondateur, qui y voyait l’intervention la plus déterminante de l’histoire du pays. Si vous l’avez manqué, le post est ici.

Ce que j’en retiens, ce n’est pas le débat pro clim ou non. C’est que le réflexe local consiste à identifier la condition qui bloque tout le reste, puis à l’assumer comme un investissement, quel qu’en soit le coût.

Gardez ce réflexe en tête. On va le retrouver appliqué à l’IA juste après.

Le détail qui m’a le plus appris : des innovateurs prudents

Contrairement au cliché du hub futuriste qu’on pourrait se faire d’une ville comme Singapour, la culture d’affaires du pays est prudente. Les PME locales refusent d’essuyer les plâtres : personne ne veut être le premier à tester une technologie, on attend qu’elle soit éprouvée.

Un état d’esprit qui ressemble bien plus au nôtre qu’à celui de la Silicon Valley.

Et pourtant. Dans toutes les organisations que j’ai rencontrées, l’IA dans le développement est déjà rangée dans la catégorie des technologies éprouvées. Même les prudents y sont allés.

Poussons le raisonnement jusqu’au bout. Si même les plus frileux ont déjà passé le cap, « attendre que ça mûrisse » ne décrit plus de la prudence. Ça décrit un retard.

Pourquoi eux, et pas nous ?

Alors, qu’est-ce qui a clos le débat là-bas ? Sûrement pas un supplément de conviction.

À Singapour, l’IA n’a jamais été une affaire d’opinion. Priorité décrétée au plus haut niveau, moyens engagés, et l’État qui commence par se l’appliquer à lui-même, exactement comme il l’avait fait pour la clim. La question a été tranchée au niveau du système, les conditions ont suivi. Il ne restait plus rien à débattre. Seulement à organiser.

Regardez maintenant nos organisations. Chez nous, l’IA reste le plus souvent une opinion : le CTO a la sienne, les développeurs ont les leurs, le comité de direction en a plusieurs, et chacune se défend en réunion. Or une opinion ne se démontre pas, elle se discute. Le débat est donc structurellement sans fin.

La conviction compte, bien sûr. Mais ce qui met fin à un débat, c’est une décision prise au bon niveau, puis des conditions qui la rendent exécutable.

J’entends l’objection d’ici : « on n’est pas Singapour ». C’est vrai. Une cité-État de six millions d’habitants avec un exécutif fort, rien de tout ça n’est transposable, et je ne vous propose pas de le transposer. Ce qui se transporse, c’est le mécanisme : décider explicitement, créer les conditions, en assumer le coût. Ça tient dans une organisation de 80 personnes comme dans un pays.

La suite

Le prochain épisode entre directement dans les bureaux de deux scale-ups Singapouriennes, là où ce mécanisme produit ses effets les plus concrets. Deux stratégies opposées avec la même technologie. Dont une où l’équipe technique de 50 personnes construit le système qui la réduira à 20 d’ici la fin de l’année. Avec l’accord total de l’équipe.

Rendez-vous fin août. Je vous raconterai pourquoi ils sont d’accord.

PS : ce carnet gagne à circuler. Si un dirigeant de votre entourage se pose encore « la question », transférez-lui cet épisode :)

Partager

👋 Bonjour,

Ce mois-ci, on vous a sélectionné 6 ressources autour d’une question devenue centrale pour un dirigeant : que devient votre équipe tech quand la machine écrit une grande partie du code, et quels arbitrages faut-il anticiper cette année ?

A première vue les sujets semblent séparés : le rôle des développeurs qui se déplace, la taille des équipes qui se réduit, la facture de l’IA qui grimpe, une dépendance aux fournisseurs de modèles qui s’installe.

Ils viennent pourtant d’un même mouvement.

Quand le code se produit presque tout seul, le travail humain remonte d’un cran, vers le cadrage et le contrôle de ce que produisent les modèles. Et la fabrication elle-même devient un service qu’on loue à l’usage, sur des modèles qu’on ne possède pas.

Ce déplacement a deux conséquences directes.
D’un côté, vos équipes : quels profils recruter, combien de personnes, faut-il encore former des juniors. De l’autre, l’économie de cette nouvelle façon de produire, ce qu’elle vous facture réellement et ce dont elle vous rend dépendant.

La forme que prendra votre organisation tech dans les prochaines années se joue dans les arbitrages que vous posez maintenant.

🗞️ Les articles du mois

1. L’équipe tech de 2030 : ce qui change vraiment avec l’IA

→ Lire : Équipe tech 2030 : ce qui change vraiment avec l’IA – Hones

La plupart des discussions sur l’IA et le code s’arrêtent au gain de productivité. Cet article regarde ce que devient concrètement le travail quand le modèle produit une grande partie du code : le développeur devient architecte, cadre le besoin et vérifier ce qui sort.

✅ Pourquoi le lire ?

Parce qu’il est écrit pour votre poste, pas pour celui de votre CTO. Il décrit la transformation depuis l’intérieur d’une équipe tech, avec ce qu’elle implique directement pour vos arbitrages de dirigeant.

Ce qui mérite qu’on s’y arrête :

• Le piège du CEO qui court-circuite sa tech. Maintenant que n’importe qui peut prototyper avec un outil IA, la tentation est de commander des fonctionnalités en direct, sans passer par ses équipes. Ça va plus vite sur le moment. L’article montre ce que ça crée derrière : du shadow IT, des bouts de produit qui ne se parlent pas, et une cohérence technique qui se perd.

• Le product engineer comme nouveau centre de gravité de l’équipe. Comprendre ce profil change la façon dont vous écrivez vos prochaines fiches de poste, et la façon dont vous évaluez ceux qui sont déjà là.

💡 À retenir : Avant de commander une fonctionnalité directement à un outil IA, regardez ce que ça déplace dans votre équipe. Le gain de la semaine peut coûter cher au trimestre suivant.

2. Ne plus recruter de juniors : le calcul qui se retourne contre vous

→ Lire : Les mythes de l’IA – Debunk #3 : « L’IA va remplacer les développeurs juniors dès 2026 » – Maddyness

La tentation est compréhensible : si la machine code, à quoi bon recruter des juniors ?
A première vue les chiffres semblent donner raison à ce réflexe. Le Stanford Digital Economy Lab a documenté une baisse proche de 20 % de l’emploi des développeurs de 22 à 25 ans aux États-Unis entre fin 2022 et mi-2025. En France, l’Apec prévoit une hausse des recrutements de cadres informaticiens en 2026, mais les profils de moins de six ans d’expérience n’y progressent que de 1 %.
Yann Lechelle, entrepreneur et dirigeant dans la tech, signe ici une tribune qui prend de la hauteur sur ces données et conteste la conclusion qu’on en tire.

✅ Pourquoi le lire ?

Parce qu’il s’adresse au dirigeant avec une grille financière, et qu’il ne se contente pas de nommer le problème : il propose des actions concrètes.

Quelques points qui changent la lecture :

• La bonne question financière n’est pas combien vous économisez en ne recrutant plus de juniors. C’est ce que vous coûtera, en 2030, de ne pas avoir de seniors parce que vous n’en aurez pas formé entre 2024 et 2028.

• Le compagnonnage change de contenu. Le senior ne montre plus comment faire, il montre comment vérifier une sortie, isoler un biais, reproduire un résultat. Le métier se rapproche de celui du chercheur.

• Le temps senior consacré à former devient un investissement. La même matière qui manque pour encadrer un junior manquera demain pour gouverner un agent.

• L’AI Act européen, dont les principales obligations s’appliquent à partir d’août 2026, demandera une supervision humaine traçable. Personne ne la produira sans un vivier formé en amont.

💡 À retenir : Couper l’entrée des juniors aujourd’hui revient à décider qu’on manquera de seniors à former demain. Le coût ne se voit pas tout de suite, c’est ce qui le rend facile à ignorer.

3. L’IA partout ? Le coût du token a déjà choisi pour vous

→ Lire : L’IA partout ? Le coût du token a déjà choisi pour vous – Journal du Net

Le 1er juin 2026, GitHub Copilot a basculé toutes ses offres en facturation à l’usage. Le forfait à accès illimité, sur lequel beaucoup d’équipes s’étaient installées, disparaît : chaque token est mesuré puis refacturé, et la dépense suit l’adoption au lieu d’être fixée d’avance. Le même mois, Fortune rapportait que l’usage agentique pouvait, sur certains workflows, revenir plus cher qu’un développeur humain. L’article prend le sujet par l’angle de la décision plutôt que de l’inquiétude.

✅ Pourquoi le lire ?

Parce qu’il rend le coût de l’IA pilotable, usage par usage.

Ce que vous pouvez en tirer :

• Les tarifs affichés ne disent pas tout : à la sortie d’Opus 4.7, Anthropic a gardé ses prix nominaux, mais son nouveau tokenizer produit jusqu’à 35 % de tokens en plus pour un texte identique. La note grimpe sans qu’aucun tarif n’ait bougé.

• Côté productivité, le rapport DORA 2025 de Google Cloud (près de 5 000 réponses) montre que 90 % des développeurs utilisent l’IA, mais que ce gain individuel ne se transforme pas mécaniquement en gain pour l’organisation.

• Sa réponse : passer de « l’IA partout » à une logique d’allocation, via une grille de cinq questions qui trie chaque usage entre quatre zones, de celui qu’on industrialise à celui qu’on arrête. Sans quoi on épuise un budget annuel en quatre mois.

💡 À retenir : La question à poser en comité, pour chaque usage : ce qu’il rapporte dépasse-t-il ce qu’il consomme en tokens ? Tant que vous ne savez pas y répondre, c’est la facture qui décide à votre place.

4. La dépendance s’installe sans que vous l’ayez décidée

→ Lire : Agents IA : la facture qui surprend, les modèles qui disparaissent… – Journal du Net

Personne ne décide un matin de dépendre d’un fournisseur. La dépendance s’installe par commodité, jusqu’au jour où partir coûte cher. Selon une enquête Parallels de février 2026 menée auprès de 540 professionnels de la tech en Europe et aux États-Unis, 94 % des responsables informatiques identifient désormais le vendor lock-in comme un risque, et seulement 6 % estiment pouvoir changer de fournisseur sans conséquences sérieuses.

✅ Pourquoi le lire ?

Parce qu’il documente la dépendance par des cas datés et nommés :

• Un modèle sur lequel repose votre produit peut disparaître vite. L’article aligne les cas : retraite de GPT-4o et GPT-4.1 (OpenAI) pour octobre 2026, licences Claude Code résiliées par Microsoft faute de rentabilité, et le 12 juin 2026, deux modèles d’Anthropic coupés par décision gouvernementale américaine pour tous ses clients.

• Le déséquilibre est aussi contractuel : selon une analyse de la Stanford Law School (2025), 92 % des grands fournisseurs revendiquent des droits étendus sur les données qui transitent par leurs systèmes. En toile de fond, l’AI Act prévoit des sanctions jusqu’à 7 % du chiffre d’affaires mondial.

• La parade : garder une architecture multi-modèles capable de basculer en quelques heures, sans tout miser sur un fournisseur. L’article cite l’open source, dont Kimi K2.6, plusieurs fois moins cher. Gartner estime que plus de 40 % des projets agentiques seront abandonnés d’ici 2027.

💡 À retenir : Choisir un modèle aujourd’hui, c’est aussi se donner les moyens d’en changer demain. Cette porte de sortie se construit dès maintenant.

🎬 L’espace média

Pourquoi le « token maxing » fait échouer les startups – CTO de Legora

→ Écouter : Pourquoi le « token maxing » fait échouer les startups – Jacob Lorettson, CTO de Legora (~57 min)

Legora a atteint 100 millions de dollars d’ARR en dix-huit mois, et plus de la moitié de son code est aujourd’hui générée par IA. Son CTO, Jacob Lorettson, raconte ce que ça a changé pour son organisation, les recrutement et les coûts. Un retour d’expérience complet de quelqu’un qui construit l’équipe en temps réel, avec les arbitrages que ça impose.

✅ Pourquoi l’écouter ?

Parce qu’au lieu d’un discours sur l’avenir du métier, vous entendez les décisions concrètes d’un dirigeant tech, y compris celles qu’il regrette.

Ce qui ressort de l’échange :

• La taille d’équipe l’a surpris. Il pensait plafonner à une vingtaine d’ingénieurs, ils sont 80 et continuent de recruter. Viser une équipe minimale a ses limites, et il le raconte honnêtement.

• Sa recommandation la plus forte porte sur la developer experience team, l’embauche qu’il aurait dû faire plus tôt : une petite équipe dont le seul travail est de rendre les autres plus rapides, en outillant la revue, l’intégration continue et les agents.

• Sur le « token maxing » : mettre la consommation de tokens dans un classement ou dans les entretiens annuels pousse les équipes à en gaspiller pour bien paraître. Le budget tokens doit se raisonner en coût d’opportunité, pas en plafond.

• Sur la dépendance aux modèles, son point est net : ils en évaluent une dizaine en parallèle, changent souvent, et leurs clients resteraient même si on leur retirait le modèle. La valeur est dans tout ce qu’ils ont construit autour.

💡 À retenir : Récompensez ce que vos équipes produisent, pas le nombre de tokens qu’elles brûlent pour le montrer. Et gardez toujours la possibilité de changer de modèle, parce que le meilleur du moment ne le restera pas longtemps.

De combien de personnes votre organisation a-t-elle vraiment besoin ?

→ Regarder : One-person billion-dollar company : cas américain ou prochain standard ? – Hones

La discussion démarre sur une question que peu de dirigeants posent aussi directement : de combien de personnes votre organisation a-t-elle besoin pour produire ce qu’elle produit aujourd’hui ? Le reste de l’échange regarde ce qui a bougé dans les organisations françaises en douze mois, et ce que les fonds observent désormais quand ils ouvrent un dossier.

✅ Pourquoi le regarder ?

Parce que c’est le seul contenu de cette édition qui apporte un point de vue investisseur. La taille de votre équipe ne se joue plus seulement en interne, elle est devenue un élément que vos financeurs regardent de près.

Ce qui mérite attention :

• Le ratio effectif sur impact a changé. Plusieurs startups et scale-ups françaises l’ont fait évoluer en un an, et le live s’appuie sur des exemples du terrain local auxquels on peut s’identifier.

• Ce que les fonds regardent autrement dans une équipe tech. Si une levée est à l’horizon, c’est la partie à écouter en priorité, parce qu’elle est difficile à percevoir depuis l’intérieur.

• Les erreurs qui font échouer un projet IA avant même la mise en production.

💡 À retenir : Si une levée se profile, écoutez surtout ce que les deux intervenants disent de la taille d’équipe. C’est l’angle que vous ne verrez pas venir depuis l’intérieur de votre organisation.

À très vite,

— L’équipe Hones

Dans ce premier épisode de “De vive voix”, Joachim Fourquet, CEO de Hones, reçoit Emma pour revenir sur cette croissance. La singularité de cet échange : une collaboration qui a duré plus de quatre ans. Hones a construit la plateforme de Slash et assuré le rôle de CTO part-time, jusqu’à organiser le recrutement du CTO interne qui lui a succédé.

On y parle de la genèse du modèle (une idée née d’un achat immobilier), de ce que change une plateforme propriétaire quand un fonds étudie votre dossier, de comment piloter une roadmap tech quand on n’est pas technique soi-même, et du moment où le modèle part-time atteint ses limites.

Au programme :

→ Une idée de business née d’un achat de maison (son père, client d’un réseau de mandataires immobiliers, lui souffle l’idée au téléphone)

→ Comment Emma a sélectionné un partenaire tech en n’ayant aucun background technique, et pourquoi les promesses des agences l’ont mise en alerte

→ Le rôle de la plateforme propriétaire dans la décision de Réflexion Capital

→ Le moment où le CTO part-time ne suffisait plus, et comment on a préparé notre propre sortie

Slash Intérim : https://slash-interim.com/

Emma Capron : https://www.linkedin.com/in/emma-capron-slash/

Joachim Fourquet : https://www.linkedin.com/in/joachim-fourquet-48b5a37/

📽️ À découvrir également sur notre chaîne YouTube.

De combien de personnes votre organisation a-t-elle vraiment besoin pour produire ce qu’elle produit aujourd’hui ?

La plupart des dirigeants français n’ont pas de réponse précise à cette question.

La one-person billion-dollar company n’est plus un fantasme. Des organisations de plus en plus petites génèrent des résultats qui étaient réservés jusqu’ici à des mastodontes.

Mais quand on est une boîte française avec un ERP, des process figés depuis des années et des clients qui appellent : est-ce vraiment transposable, ou c’est encore un succès américain déconnecté de nos réalités ?

C’est ce qu’on aborde dans cette vidéo :

• Qu’est-ce qui a vraiment changé dans les organisations françaises en 12 mois ?

• Comment des startups / scaleups françaises ont commencé à modifier leur rapport effectif/impact ?

• Qu’est-ce que les fonds regardent différemment dans un dossier aujourd’hui ?

• Quelles sont les erreurs qui tuent les projets IA avant qu’ils passent en production ?

🎤 Replay d’un live animée par Joachim Fourquet, avec :

• Matthias Baccino - Markets Group Lead Europe chez Trade Republic

• Chloé Novène - Investment Director Venture chez BlackFin

• Matthieu Sénéchal - CTO et co-fondateur d’Hones

👋 Bonjour,

Ce mois-ci, on vous a sélectionné 5 ressources autour d’une question que peu de dirigeants se posent vraiment : à quel stade de maturité IA se trouve leur entreprise ?

La plupart ont testé des outils, lancé des pilotes, observé quelques gains. Mais quand on regarde ce qui a vraiment changé dans l’organisation, la réponse est souvent plus modeste que ce qu’on se racontait.

Au programme :

• Ce que signifie vraiment être une organisation IA mature, niveau par niveau

• Ce que les données de 1 000 dirigeants révèlent sur le lien entre stade de maturité et ROI réel

• Ce que ça change dans votre posture de CEO, pas seulement dans vos outils

Et en bonus, un test de 10 minutes pour vous positionner précisément sur les 4 niveaux de maturité et identifier ce qui freine réellement votre progression.

Pas de hype, pas de concepts abstraits : que du concret pour les dirigeants qui veulent savoir où ils en sont et ce que ça leur coûte de ne pas avancer.

🗞️ Les articles du mois

1. Les 4 niveaux de maturité IA : où se situe votre équipe tech ?

→ Lire : Maturité IA : 4 niveaux pour situer votre équipe tech

La plupart des équipes tech pensent être déjà mature sur leur process IA. Les données terrain montrent que beaucoup sont encore au niveau 1, parfois entre le 1 et 2, mais rarement où elles se croient. Ce décalage n’est pas anodin : une équipe qui se situe mal va investir sur les mauvais sujets et s’étonner que les résultats ne suivent pas.

Cet article propose un modèle en 4 niveaux : ce qui définit votre maturité IA, ce n’est pas la quantité d’outils adoptés. C’est l’endroit où se situe le goulot dans votre pipeline de développement. À chaque niveau, ce goulot se déplace, et c’est ce déplacement qui dit où vous en êtes réellement.

✅ Pourquoi le lire ?

Parce que ce contenu décrit la maturité IA depuis l’intérieur d’une équipe tech, avec le niveau de précision qui permet à un CEO de comprendre ce qui se passe vraiment dans son organisation technique.

Ce qui mérite attention :

• Le piège du niveau 1 : vos développeurs utilisent Copilot ou Cursor, le code sort plus vite, et pourtant les livraisons ne s’accélèrent pas. Avec un volume de pull requests en hausse de 91%, c’est la revue de code qui devient le nouveau goulot. Les seniors passent leur temps à valider plutôt qu’à construire, et comme personne ne mesure le temps passé en revue, le problème reste invisible pendant des mois.

• La “taxe vitesse” : les équipes qui adoptent l’IA sans restructurer leurs process en aval se retrouvent avec 1,7 fois plus de problèmes dans leurs pull requests. Plus de code, pas forcément plus de valeur livrée.

• Ce que font les organisations au niveau 3 : Stripe traite plus de 1 300 pull requests générées par IA chaque semaine. Ce qui les distingue n’est pas l’outillage. Ce sont les systèmes de gouvernance qu’elles ont construits autour.

💡 À retenir : “90% des équipes tech utilisent l’IA aujourd’hui. Seulement 32% ont une gouvernance formalisée en place. L’écart entre ces deux chiffres est exactement l’espace où se perdent les gains potentiels.”

2. Le piège que personne ne voit : vous optimisez des tâches, pas votre business

→ Lire : How to Move from AI Experimentation to AI Transformation – Harvard Business Review

Il y a un nom pour ce que vivent la plupart des entreprises qui ont commencé à déployer l’IA : le “micro-productivity trap”. Vos équipes gagnent du temps sur des tâches précises. Les outils fonctionnent. Et pourtant, rien ne change dans vos marges.

Cet article co-écrit par des partners de Bain et des membres de l’équipe économique d’OpenAI documente deux ans de déploiements IA dans des entreprises de tailles et secteurs variés. Leur conclusion est inconfortable pour beaucoup de dirigeants : ce qui bloque n’est presque jamais la tech. C’est la manière dont l’organisation autour continue de fonctionner comme avant.

✅ Pourquoi le lire ?

Parce qu’il nomme avec précision ce qui sépare une entreprise qui “utilise l’IA” d’une entreprise qui “se transforme par l’IA”.

Ce qui mérite qu’on s’y arrête :

• Le micro-productivity trap : l’IA accélère une tâche, mais si le workflow autour repose encore sur des handoffs manuels et des systèmes non interconnectés, le gain s’évapore avant d’atteindre le résultat business. C’est le cas de la grande majorité des déploiements actuels.

• Les entreprises qui s’en sortent ne partent pas de “comment améliorer ce process ?”. Elles partent de “si on reconstruisait tout avec l’IA comme hypothèse de base, comment ferait-on ?”. Le changement de question change tout ce qui suit.

• Les résultats sont mesurables : 10 à 25% de gains EBITDA chez les clients Bain qui ont fait cette bascule. Chez FabricationCo, la génération de devis est 15 fois plus rapide, avec 10 points de win rate gagnés en trois mois.

💡 À retenir : “L’IA peut accélérer une tâche. Mais si l’organisation autour n’a pas bougé, le gain n’atteint jamais le compte de résultat.”

3. Ce que 1 000 dirigeants révèlent sur le lien entre maturité IA et valeur créée

→ Lire : 7 Factors That Drive Returns on AI Investments, According to a New Survey – Harvard Business Review

71% des directeurs tech dans le monde déclarent que leur budget IA sera gelé ou réduit si la valeur créée ne peut pas être démontrée dans les deux ans. La pression sur les dirigeants est réelle, et elle ne vient pas des équipes tech.

Thomas Davenport, l’un des chercheurs les plus cités sur l’IA en entreprise, a interrogé 1 006 dirigeants senior dans le monde et mené 12 entretiens approfondis avec des responsables IA de grandes organisations. Ce qu’il trouve va à l’encontre de plusieurs idées reçues.

✅ Pourquoi le lire ?

Parce que c’est une des seules études qui établit une corrélation directe et chiffrée entre niveau de maturité et ROI réel.

Ce qui change vraiment la lecture :

• Les organisations qui n’ont que des pilotes sans jamais évaluer leur impact business (Stage 0) ne sont que 4% à déclarer beaucoup de valeur. Celles qui mesurent systématiquement le ROI de chaque déploiement en production (Stage 3) passent à 44%. Celles qui agrègent cette valeur à l’échelle de l’entreprise et la reportent formellement au board ou aux investisseurs (Stage 5) atteignent 85%. Il y a deux points d’inflexion majeurs dans cette progression, et les franchir change qualitativement ce qu’on retire de l’IA.

• Ce qui fait la différence n’est pas le modèle choisi ni le budget alloué. C’est l’implication de la finance dans la validation des résultats : les organisations où le CFO est responsable de la valeur IA déclarent 76% de “grande valeur”, contre 32% pour les équipes fonctionnelles seules.

• La réduction d’effectifs n’est pas encore un driver de valeur réel. Seulement 2% des réductions annoncées sont activées par des capacités IA en production. Ce n’est pas là que ça se joue à court terme.

💡 À retenir : “Le chemin vers la valeur IA n’est pas principalement un problème technique. C’est un problème de management. Chaque organisation a maintenant accès à la technologie. Ce qui les sépare, c’est comment elles la pilotent.”

4. Le vrai test : êtes-vous, vous-même, prêt à piloter cette transformation ?

→ Lire : The AI Upskilling Guide for Executives – Bessemer Venture Partners

Seulement 1% des dirigeants dans le monde déclarent que l’IA est pleinement intégrée dans leurs workflows et génère des résultats business substantiels. Ce chiffre, issu d’une étude McKinsey citée par Bessemer Venture Partners, n’est pas une statistique sur la technologie. C’est une statistique sur les organisations, et sur ceux qui les pilotent.

Ce guide, construit par l’un des fonds VC les plus actifs sur les sujets IA, s’adresse directement aux dirigeants. Son point de départ est simple : une transformation IA qui réussit commence par un CEO qui s’est lui-même transformé.

✅ Pourquoi le lire ?

Parce que les articles précédents parlent de l’organisation. Celui-ci parle du dirigeant. Et c’est souvent là que se joue la progression.

Ce qui mérite attention :

• Le tableau “red flags / green flags” est un outil immédiatement utilisable. En dix minutes, il permet de prendre la température de sa propre posture et de celle de ses équipes. La plupart des dirigeants qui le lisent y reconnaissent plusieurs signaux qu’ils n’avaient pas nommés comme tels.

• Sur la résistance des équipes, les données sont contre-intuitives : seulement 13% des organisations la citent comme frein à l’adoption. Le vrai frein est l’absence de cadre et de leadership clair. Les employés n’attendent pas de convaincre. Ils attendent qu’on leur montre.

• Les organisations qui forment à la fois les employés et les dirigeants voient une progression sur la création de valeur par rapport à celles qui ne forment que les équipes.

💡 À retenir : “Les employés ne résistent pas à l’IA. Ils attendent un leadership clair et des outils accessibles. Ce qui bloque n’est presque jamais en bas de l’organigramme.”

🎬 L’espace média

Comment Zapier a transformé toute son organisation en une semaine

→ Regarder : Les enseignements de la transformation de Zapier par l’IA – Modern CTO (~40 min)

Wade Foster est co-fondateur et CEO de Zapier, l’outil d’automatisation que beaucoup utilisent. 15 ans d’existence, 5 milliards de dollars de valorisation, bootstrappée depuis le départ. En 2023, il a déclenché ce qu’il a appelé un “code red” dans toute l’organisation.

✅ Pourquoi le regarder ?

Parce que Zapier n’est pas une multinationale avec un département transformation de 50 personnes. C’est une scale-up bootstrappée avec les mêmes contraintes que beaucoup d’autres entreprises de taille moyenne.

Ce qui ressort de l’échange :

• Lors du lancement de Chat-GPT, Zapier avait réagi comme beaucoup : un message dans Slack, un “regardez ce truc intéressant”, et on continue. C’est GPT-4, six mois plus tard, qui a changé la lecture. Le bond de qualité et la baisse de coût entre les deux versions étaient suffisamment nets pour ne plus ressembler à une amélioration incrémentale. Wade Foster y a vu une tendance, pas un événement. Il mobilisé toute l’organisation en quelques jours. Son raisonnement : deux points de données suffisent pour extrapoler.

• La décision la plus impactante : arrêter l’entreprise pendant une semaine pour un hackathon tous départements confondus. Le taux d’utilisation hebdomadaire de l’IA est passé de moins de 10% à plus de 50% en sept jours. Il a fallu encore un an pour atteindre 100%. La transformation culturelle ne fonctionne pas comme un interrupteur.

• Zapier évalue maintenant tous ses candidats sur leur maturité IA, avec un référentiel à quatre niveaux construit fonction par fonction, mis à jour tous les six mois. Parce que les use cases évoluent plus vite que les processus de recrutement.

💡 À retenir : “Quand les gens mettent les mains sur le clavier, la peur disparaît. Ce n’est pas la communication interne qui change la culture. C’est l’expérience directe.”

🤖 Quel est le niveau de maturité IA de votre entreprise ?

→ Faites le test : Test de maturité IA – Hones (10 min)

Ce test a été conçu à partir de dizaines de missions aux côtés de dirigeants tech. En 10 minutes, il positionne votre organisation sur les 4 niveaux de maturité IA, identifie le goulot qui freine réellement votre progression, et produit trois actions concrètes calibrées à votre situation.

Pas de recommandations génériques : le résultat est directement actionnable par vos équipes.

À très vite,

— L’équipe Hones

Vous avez aimé cette newsletter ? N’hésitez pas à la partager dans votre réseau.

Partager TechRadar by Hones

Autonome, concentré, productif parce qu’il est coupé du reste. C’est une réalité partielle qui est devenue une représentation dominante du métier. Et elle coûte cher.

Pas parce que le travail en solo est inefficace en soi. Parce qu’il crée un angle mort : comprendre le problème qu’on est censé résoudre. Un profil tech peut maîtriser parfaitement son domaine et livrer une solution irréprochable sur le plan technique, qui ne sert à rien dans la pratique. Ce n’est pas rare. C’est même assez systématique dans les projets qui dérivent.

Ce qui fait fonctionner une équipe tech, c’est rarement le niveau technique moyen. C’est la capacité collective à aller chercher l’information là où elle est, souvent dans une conversation avec quelqu’un qui vit le problème de l’intérieur.

Une réflexion courte là-dessus en vidéo.

Il y a quelques semaines, Philippe, CTO part-time de l’équipe, montait sur scène au Dataquitaine pour raconter comment Hones a construit Miska, un outil interne qui automatise une bonne partie de notre méthode d’audit.

Un vrai retour terrain, sans filtre, avec les bugs inclus.

Le problème de départ n’est pas technique

Chez Hones, on fait du conseil tech et produit. Notre valeur, c’est une expertise terrain accumulée sur des missions d’accompagnement de dirigeants. Mais cette expertise vivait dans des templates Notion, des trames de slides, des checklists éparpillées. Un travail manuel conséquent, difficile à répéter et encore plus à faire monter en charge.

L’idée de Miska est née de là. Pas d’un désir de faire de la tech pour la tech, mais d’une question concrète : est-ce qu’on peut automatiser ce qu’on fait à la main sans perdre ce qui fait la qualité de notre méthode ?

Un outil développé en 15 jours.

La plateforme couvre l’intégralité du workflow d’audit : tableau de bord, gestion du périmètre, base documentaire, planification des entretiens, prise de notes structurée, construction des constats et génération du rapport final. Du début à la fin.

15 jours de développement effectif. Front, back, agents IA spécialisés inclus.

Ce chiffre a fait lever des mains dans la salle lors de la conférence, et c’est normal.

On le reconnaît volontiers : c’est ridiculement peu comparé à ce que ça aurait représenté il y a quelques années avec un UX designer, un PM, plusieurs développeurs sur plusieurs mois. Sur les phases de production documentaire, notre vélocité a été multipliée par deux, avec 100% de la méthode Hones embarquée dans l’outil.

Ce qui a rendu ça possible : BMAD

Le cœur de notre approche, c’est le framework open source BMAD (Breakthrough Method for Agile AI-Driven Development). L’idée centrale : plutôt que de balancer des prompts en vrac à un LLM généraliste, on orchestre des agents spécialisés qui ont chacun un rôle précis, un contexte limité, des artefacts à produire.

Un agent analyste. Un agent PM. Un agent architecte. Un agent développeur. Chacun reçoit uniquement ce dont il a besoin. Un choix délibéré, car avec un contexte trop large, l’agent commence à compenser ce qu’il ne comprend pas.

Mais BMAD n’a de valeur que si la spécification en entrée est solide. Ce qu’on a appris rapidement : si on n’est pas capable d’expliquer fonctionnellement son métier à un humain, on ne sera pas capable de l’expliquer à un agent. L’outil amplifie la clarté, il n’en génère pas.

La phase de conception dans BMAD inclut ce qu’on appelle la “revue adversariale” : l’agent PM soulève les incohérences, force à trancher avant même qu’une ligne de code soit écrite. Un dernier filet avant le développement.

La où on s’est plantés

Premier écueil : partir trop grand. Avoir des ambitions larges ne pose pas de problème en soi, mais vouloir tout automatiser d’un coup génère exactement le problème qu’on cherche à éviter. Des contextes trop vastes, des agents qui mélangent les sujets, des résultats qui dérivent.

Deuxième point : la démo ne suffit pas. Un cas test qui fonctionne bien une fois ne dit rien sur ce qui se passe en conditions réelles sur quinze missions différentes. Chaque prompt doit être réévalué sur des cas terrain variés.

Et l’UX, qu’on a sous-estimée. On a envisagé un formulaire, même un chatbot à un moment. Notre vélocité nous a permis de corriger le tir rapidement, de construire un vrai design system et de repartir sur des bases plus solides.

Une direction claire pour les années avenir

Il y a dix ou quinze ans, on faisait du sur-mesure. Puis l’industrie a basculé vers le SaaS, la modularité, essayer de faire tenir ses besoins dans des outils standardisés. Avec des méthodes de développement comme celle-là, le sur-mesure redevient viable économiquement. On en a eu la confirmation concrète : un outil de back-office complet spécifié et livré pendant un trajet Paris-Brest, utilisable le lendemain midi.

L’étape d’après pour nous, c’est de passer de l’outil structuré à un vrai sparring partner : un agent à gauche, le livrable à droite, et une itération continue sur tout processus intellectuel, que ce soit pour préparer une proposition commerciale, rédiger un rapport ou structurer une décision.

Une startup qui levait 5M€ pour construire son produit peut aujourd'hui le faire avec deux fois moins, en deux fois moins de temps.

Ce n'est pas une hypothèse, c'est ce que vivent déjà les équipes tech les plus avancées.

Cycles raccourcis, coûts compressés, PMF atteint plus vite : l'IA est en train de réécrire les fondamentaux du build, et avec eux, toute la logique du financement de l'innovation tech.

Ce glissement soulève une question que personne dans l'écosystème n'a vraiment envie de poser à voix haute : si les startups ont objectivement besoin de moins de capital, comment le rôle des fonds d’investissement va-t-il évoluer ?

Le système de financement de la tech tel qu’on le connaît s’apprête à vivre un vrai basculement.

Lever des fonds est-il en train de passer de rite de passage à aveu de faiblesse ?

Les business angels et accélérateurs captent-ils mieux la réalité des startups tech d'aujourd'hui ?

Et si le réseau et l'expérience opérationnelle étaient devenus la vraie denrée rare

🎤 Replay d’un échange animée par Joachim CEO de Hones, avec :

• Olivier Tilloy, Managing Director chez Techmind

• Matthieu Sénéchal, CTO de Hones

👋 Bonjour,

Ce mois-ci, on vous a sélectionné 5 ressources autour d’une question centrale : comment construire une organisation capable d’encaisser les chocs et d’en sortir renforcée ?

L’environnement dans lequel vous pilotez votre entreprise a changé plus vite que la plupart des organisations ne se sont adaptées. Les cycles technologiques raccourcissent, le contexte économique et géopolitique est devenu difficile à lire sur plus de quelques mois, de nouveaux acteurs arrivent sur vos marchés sans porter le poids de votre historique. Et en interne, les attentes de vos équipes ne ressemblent plus à celles d’il y a cinq ans.

Les questions qu’on va aborder dans cette édition :

• Pourquoi les modèles stratégiques classiques ne suffisent plus, et ce qui les remplace

• Ce que signifie planifier quand l’horizon de visibilité se réduit

• La dette que personne ne mesure, et qui détermine si vos équipes tiennent ou lâchent sous pression

• Ce que font concrètement les fondateurs qui traversent les crises

Pas de hype, pas de concepts abstraits. Que du concret pour les dirigeants qui ne veulent plus subir la tech.

Pour plus de contenus découvrez notre chaîne youtube.

Si vous n’êtes pas abonnés, voici ce que vous avez manqué dans les éditions précédentes :

1. Comment savoir si votre équipe tech est vraiment efficace ?

2. Transformer l’existant : le défi IA des entreprises établies

3. Ce que l’IA change (vraiment) dans la manière de piloter une entreprise

🗞️ Les articles du mois

1. Le modèle Bambou : repenser l’organisation pour un monde imprévisible

→ Lire : Le modèle Bambou – Harvard Business Review France

Les cadres stratégiques sur lesquels la plupart des entreprises fonctionnent encore (la pyramide hiérarchique, le plan à 5 ans, Porter, …) ont été pensés pour un monde où les marchés bougeaient lentement. Ce monde-là n’existe plus, mais les réflexes, eux, sont restés.

Cet article de HBR France propose autre chose. Le bambou comme métaphore : des racines profondes (valeurs, identité, compétences clés), des tiges flexibles (équipes, process, allocation de ressources), et surtout une capacité à plier sous la pression sans casser.

✅ Pourquoi le lire ?

C’est le seul article récent qui propose un modèle à la fois stratégique et organisationnel pour remplacer les cadres hérités du siècle dernier. Pas un simple ajustement, mais un changement de paradigme complet.

Quelques points qui méritent qu’on s’y arrête :

• La rigidité organisationnelle n’est pas un problème de process. C’est un problème de modèle mental. Tant que vous penserez votre entreprise comme une pyramide, vous optimiserez la stabilité. L’adaptabilité, elle, demande un autre cadre de pensée.

• Le concept de “slack organisationnel” : les entreprises les plus résilientes ne fonctionnent pas à pleine capacité. Elles conservent de la marge, en temps, en budget, en attention, pour pouvoir réagir quand le contexte bouge. Dans une scale-up où chaque euro est compté, ça demande un arbitrage conscient.

• La distinction entre ce qui doit rester stable (les racines : mission, culture, compétences clés) et ce qui doit pouvoir bouger rapidement (roadmap, allocation d’équipes, go-to-market). Cette grille est un outil de décision utilisable dès votre prochain comité de direction.

💡 À retenir : “La solidité d’une entreprise ne se mesure plus à sa rigidité, mais à sa capacité à plier sans rompre.”

2. 2026 : la fin des roadmaps tech sur 12 mois

→ Lire : La fin des roadmaps tech sur 12 mois – Hones

Votre roadmap produit sur 12 mois que vous avez validée en décembre, a-t-elle survécu au premier trimestre ? Si la réponse est “pas en l’état’, le problème n’est probablement pas l’exécution.

Cet article prend une position franche : dans un environnement où les modèles IA changent tous les trimestres, où un concurrent peut émerger en quelques semaines et où les attentes clients bougent en continu, planifier sur 12 mois relève davantage du réflexe que de la véritable stratégie.

✅ Pourquoi le lire ?

Cette article ne conseille pas d’arrêtez de planifier. Il propose de changer ce que vous planifiez et comment vous le faites.

La distinction centrale : le cap (stable, à 12-18 mois) versus le chemin (flexible, révisé toutes les 6 à 8 semaines). Le cap, c’est votre vision produit et vos paris stratégiques. Le chemin, c’est la séquence d’exécution. Et cette séquence doit pouvoir évoluer sans que ça déclenche une remise en question existentielle dans l’équipe.

L’autre idée forte : l’incertitude n’est pas un obstacle à la planification, c’est une donnée d’entrée. Les entreprises qui l’intègrent dans leur cadence de décision, avec des revues fréquentes et des décisions conçues pour être réversibles, vont structurellement plus vite que celles qui s’accrochent à un plan figé.

Un constat qui mérite d’être lu attentivement : l’incertitude redistribue les cartes en faveur des organisations légères. Les scale-ups ont un avantage structurel sur les grands groupes dans ce contexte. À condition de ne pas reproduire, par mimétisme, la lourdeur qu’elles prétendent combattre.

💡 À retenir : “Le plan à 12 mois ne vous protège pas de l’incertitude. Il vous empêche de la voir venir.”

3. Culture Debt : la dette invisible qui tue les entreprises tech

→ Lire : Culture Debt – Mike Fisher (Substack)

Vous connaissez la dette technique. Vous la mesurez, vous la priorisez, vous négociez du temps pour la résorber. Mais il existe une dette plus difficile à voir, parce qu’elle ne remonte dans aucun dashboard : la dette culturelle.

Mike Fisher, ancien CTO d’Etsy, pose un diagnostic que peu de dirigeants tech veulent entendre. Cette dette s’accumule à chaque valeur affichée mais non incarnée, à chaque feedback repoussé, à chaque comportement toxique toléré parce que la personne “délivre”.

✅ Pourquoi le lire ?

L’analogie avec la dette technique est ce qui rend cet article immédiatement saisissable pour un dirigeant tech. Vous savez ce que coûte de ne pas refactorer un module critique pendant trois ans. Mike Fisher applique le même raisonnement à la culture : accumulation silencieuse, coût de remboursement qui explose avec le temps, et un jour, un incident critique.

Les cas qu’il cite ne sont pas décoratifs. Uber a payé sa dette culturelle par une crise publique qui a coûté son poste au fondateur. Boeing a payé la sienne bien plus cher. Netflix, à l’inverse, a investi très tôt dans un système de feedback exigeant, précisément pour éviter que cette dette ne s’installe.

Le point le plus important de l’article tient en une phrase : la culture, ce n’est pas ce que vous écrivez sur un mur ou dans un onboarding deck. C’est ce que vous tolérez au quotidien. Et dans une période d’incertitude, c’est cette culture qui détermine si vos équipes tiennent ensemble ou se dispersent au premier choc.

💡 À retenir : “La culture, ce n’est pas ce que vous déclarez. C’est ce que vous tolérez.”

📅 L’évènement du mois

L’IA et le paradoxe du capital : quel avenir pour le venture capital ?

Une startup qui levait 5M€ pour construire son produit peut aujourd’hui le faire avec deux fois moins, en deux fois moins de temps.

Ce n’est pas une hypothèse, c’est ce que vivent déjà les équipes tech les plus avancées.

Cycles raccourcis, coûts compressés, PMF atteint plus vite : l’IA est en train de réécrire les fondamentaux du build, et avec eux, toute la logique du financement de l’innovation tech.

Si les startups ont objectivement besoin de moins de capital, comment le rôle des fonds d’investissement va-t-il évoluer ?

Le système de financement de la tech tel qu’on le connaît s’apprête à vivre un vrai basculement.

Un débat live, animée par Joachim CEO de Hones, avec :

• Olivier Tilloy, Managing Director chez Techmind

• Matthieu Sénéchal, CTO de Hones

📅 RDV le 14 avril à 12h

→ S’inscrire à l’évènement

🎬 L’espace média

Comment Block a transformé toute son organisation par l’IA

→ Écouter : How Block is becoming the most AI-native enterprise in the world – Lenny’s Podcast (~1h30)

Dhanji Prasanna est CTO de Block (ex-Square, Cash App, 4 000+ ingénieurs). Avant d’avoir ce titre, il a écrit un document interne qu’il appelle son “manifesto IA” et l’a envoyé directement à Jack Dorsey. Le document décrivait pourquoi Block devait repenser toute son organisation autour de l’IA. La suite : une promotion au poste de CTO, et une transformation qui ne ressemble pas à ce qu’on lit d’habitude sur le sujet.

✅ Pourquoi l’écouter ?

Parce que la plupart des transformations IA commencent par un choix d’outil et finissent dans un pilote sans suite. Chez Block, ça a commencé par une restructuration.

Ce qui ressort de l’échange :

• Le changement organisationnel “ennuyeux” (suppression de silos, clarification des responsabilités, réorganisation des équipes) a eu plus d’impact sur la productivité que le déploiement des outils IA eux-mêmes. L’IA a besoin d’une organisation saine pour produire de la valeur. Si l’organisation est dysfonctionnelle, l’IA accélère le dysfonctionnement.

• Goose, l’agent IA interne open-source de Block, fait gagner 8 à 10 heures par semaine aux employés. Le détail qui surprend : les équipes qui en profitent le plus ne sont pas les ingénieurs.

• Sa conviction sur l’adoption : si le leadership n’utilise pas les outils IA au quotidien, personne dans l’entreprise ne le fera sérieusement. La transformation se pilote par l’usage, pas par la communication interne.

• Les leçons de ses passages chez Google (Wave, Google+) ancrent le propos dans quelque chose que tout fondateur reconnaîtra : un bon produit ne suffit pas si l’organisation autour n’est pas capable de le porter.

💡 À retenir : “Avant d’acheter le prochain outil IA, demandez-vous si votre organisation est structurée pour en absorber la valeur.”

Le guide de survie du fondateur face à la crise

→ Écouter : A Founder’s Guide to Crisis Management – Lenny’s Podcast (Uri Levine) (~1h24)

Uri Levine a cofondé Waze (exit à 1,3 milliard $ avec Google). Il a fondé 10 entreprises, siégé dans 20 boards, accompagné plus de 50 startups. Il vient de publier un nouveau chapitre de son best-seller Fall in Love with the Problem, Not the Solution, entièrement consacré à la gestion de crise.

Tous les contenus de cette newsletter parlent de construire la résilience en amont. Celui-ci parle de ce qui se passe quand, malgré tout, ça casse.

✅ Pourquoi l’écouter ?

Parce qu’un podcast sur la gestion de crise par quelqu’un qui n’en a pas traversé, ça ne vaut pas grand-chose. Uri Levine a un vécu que peu d’entrepreneurs peuvent revendiquer, et il en tire des principes utilisables.

Ce qui mérite d’y prêter attention :

• Il distingue deux types de crises fondateurs, cash et produit, et explique pourquoi les confondre mène à de mauvaises décisions. Une crise de trésorerie se gère par la vitesse de restructuration. Une crise de product-market fit demande un autre type de lucidité.

• Sur la vitesse d’action : ce qui sépare les startups qui survivent de celles qui ferment, ce n’est généralement pas la qualité de l’analyse. C’est le temps écoulé entre le moment où le problème est identifié et le moment où une décision est prise.

• Son framework pour décider entre pivoter et fermer est d’une simplicité utile : la question n’est pas “est-ce que ça peut marcher ?”, mais “est-ce qu’il me reste les ressources pour tester une hypothèse de plus ?”.

• Sur la motivation des équipes en période de crise, il défend une transparence qui va plus loin que ce que la plupart des fondateurs pratiquent. Pas la transparence “on traverse un moment difficile mais on va s’en sortir”. Celle qui met les vrais chiffres sur la table et qui fait confiance aux gens pour encaisser.

💡 À retenir : “Ce qui sépare les startups qui meurent de celles qui survivent, c’est rarement la chance. C’est la vitesse à laquelle le fondateur accepte la réalité.”

À très vite,

— L’équipe Hones

Vous avez aimé cette newsletter ? N’hésitez pas à la partager dans votre réseau.

Partager TechRadar by Hones

Chez Hones, on accompagne des dirigeants tech au quotidien. On ne pouvait pas se contenter de leur dire “faites de l’IA” sans l’avoir éprouvé nous-mêmes, sur un vrai cas métier, avec de vraies contraintes.

Alors on a pris notre propre activité comme terrain d’expérimentation. On a décidé de développer un outil d’audit tech augmenté par l’IA. Dashboard de mission, notes d’analyse classées par thématique et criticité, génération de rapport avec revue collaborative.

Pas pour déléguer notre métier à la machine. Mais pour gagner du temps sur tout ce qu’il y avait autour : de la connaissance dispersée, du copier-coller, de la mise en forme. Du temps passé sur des tâches qui n’ont rien à voir avec l’analyse.

C’était un projet qu’on avait en tête depuis longtemps, sans jamais avoir le temps de s’y mettre. L’IA a changé l’équation : ce qui aurait pris des mois de développement classique est devenu faisable en side project.

Trois mois plus tard, on a des résultats qu’aucun benchmark ou keynote ne nous avait laissé imaginer.

On partage également cette expérimentation sur LinkedIn, au fil des évolutions. Pour suivre la série en temps réel, rendez-vous sur le profil de Matthieu (CTO & co-fondateur d’Hones).

Cet article condense les premiers épisodes. Voici ce qu'on a appris en chemin.

Le vrai défi : 80% de cadrage métier, 20% de technique

Au démarrage, on pensait que le challenge serait technique. Choisir le bon framework, configurer les agents, gérer les prompts. En réalité, la partie technique s’est révélée être la plus simple.

Le vrai travail, celui qui fait la différence entre un bot qui génère du texte et un outil qui apporte vraiment de la valeur, c’est de découper son métier en étapes suffisamment claires pour qu’un système puisse y contribuer.

Comprendre ce qui a de la valeur, ce qui n’en a pas, ce qu’on garde, ce qu’on délègue. Identifier les moments où l’IA peut aider et ceux où elle ne fait que compliquer. Définir les critères de qualité qui permettent de valider qu’un output est bon ou non.

Depuis qu’on travaille sur ce projet, on passe moins de temps à coder et plus de temps à se poser les bonnes questions sur notre propre métier. C’est probablement le gain le plus inattendu.

L’exemple de l’interface : comment bien briefer fait toute la différence

On a conçu l’interface complète de notre outil avec Claude. Un prototype React cliquable, hébergeable, testable. En deux jours. Sans designer.

Au départ, on voulait juste que Claude nous aide à prompter Figma. En interagissant avec lui, on s’est rendu compte qu’il pouvait générer directement le prototype. On a sauté l’étape maquette.

Mais on ne lui a pas dit “fais-moi une interface”. On a structuré l’approche par étapes.

D’abord, générer des règles UX spécifiques à notre contexte. Résultat : un fichier Markdown qui devient le cadre de conception.

Ensuite, briefer un agent avec un contexte complet : ce qu’on fait chez Hones, qui utilise l’outil, pourquoi, des exemples de nos livrables actuels, notre brand book. Briefer l’IA comme on briefe un humain qui débarque sur le projet.

Puis itérer par couches. Structure globale d’abord (menu, navigation), puis descente dans le détail de chaque page. Quand on avait une idée précise, on la donnait. Sinon, on laissait Claude brainstormer à partir des objectifs.

Et superviser constamment. Vérifier que les règles métier sont respectées, que les parcours sont cohérents. Claude propose parfois des choses qui n’ont aucun sens d’un point de vue produit. Sans bases en conception, impossible de repérer ce qui cloche ou d’orienter efficacement.

Le constat est clair : si vous ne savez pas cadrer votre métier, l’IA ne le fera pas pour vous. Elle amplifie ce qui existe déjà. Un brief flou donnera un résultat flou. Une vision claire donnera un produit utilisable.

Trois pièges qu’on a rencontrés : tout mettre dans une seule conversation (ça finit par saturer), ne pas donner d’exemples concrets (l’IA a besoin de voir vos livrables réels), et ne pas itérer brique par brique (demander l’application complète d’un coup fait perdre plus de temps qu’on n’en gagne).

Trois pivots, trois leçons

Cette compréhension du cadrage métier, on l’a acquise progressivement. Mais pour y arriver, on a d’abord dû passer par une autre phase d’apprentissage : comprendre quels outils pouvaient vraiment tenir la route.

On avait fait nos devoirs en amont. Un benchmark des orchestrateurs, une matrice de critères, un choix rationnel. Mais on a quand même fini par changer trois fois de stack en trois mois. Pas par plaisir de repartir de zéro, mais parce que chaque changement répondait à un blocage concret qu’on découvrait en avançant.

Phase 1 : N8n, quand le POC ne suffit plus

On voulait aller vite. Un outil low-code semblait être le bon compromis : configuration rapide, pas besoin de coder, on branche l’IA et c’est parti.

Le POC a fonctionné. On a validé qu’on pouvait dialoguer avec un agent, générer des constats d’audit, formatter en Excel. Techniquement, ça marchait.

Mais dès qu’on a voulu scaler, les limites sont apparues. Impossible de versionner correctement. Le déploiement nécessitait une installation locale sur chaque machine. Pas d’observabilité pour suivre les coûts et les requêtes.

Le POC tournait. Mais impossible à industrialiser.

Le problème était simple : on avait validé une hypothèse technique, pas construit un produit. Les outils low-code sont parfaits pour cette première étape, mais ils montrent leurs limites dès qu’on veut passer à l’échelle. Versioning, déploiement, observabilité : ces sujets paraissent secondaires au début, ils deviennent bloquants très vite.

Phase 2 : LangChain, mieux structuré mais encore lent

Face à ces blocages, on a repris de zéro. Cette fois, objectif clair : versioning propre, déploiement simple, observabilité complète.

On a choisi LangChain parce qu’il était le plus éprouvé. Tout était autocontenu dans un projet GitHub. Chacun pouvait cloner et bosser dessus sans dépendre d’une config externe.

Ça fonctionnait mieux. Mais on était encore sur un mode classique : on écrivait du code, on gérait des agents, on configurait. On gagnait en scalabilité, mais on perdait toujours du temps sur l’exécution.

On avait résolu les problèmes d’infrastructure, mais pas changé fondamentalement le tempo. Choisir un framework éprouvé plutôt que le dernier outil à la mode fait gagner du temps, c’est vrai. Mais avoir une meilleure structure ne suffit pas si on reste dans un mode de développement classique.

Phase 3 : BMAD, le changement de paradigme

C’est à ce moment-là, alors qu’on cherchait encore comment accélérer, qu’on a découvert BMAD, un framework de spec driven development. Par hasard. Un message sur un Discord d’anciens collègues. On a testé par curiosité, sans grande attente.

Et là, tout a basculé.

Avec BMAD, on ne code plus comme avant. On manage une équipe virtuelle : PM, dev, UX, test. On découpe des tâches, on brief, on itère. Exactement comme avec une vraie équipe. Sauf que c’est beaucoup plus rapide.

Ça ne fait pas de magie pour autant. Quand le brief est flou, le résultat l’est aussi. On gère les mêmes problèmes qu’avec une équipe classique : des specs à clarifier, des bugs à corriger, des arbitrages à faire. La différence, c’est que tout va trois à quatre fois plus vite.

La vraie découverte : l’IA ne remplace pas la compétence, elle la démultiplie.

Le learning global : le terrain bat toujours la théorie

En regardant ce parcours avec du recul, une chose est claire : N8n semblait parfait sur le papier. Sur le terrain, ça ne tenait pas. BIMAD, l’outil qui a tout changé pour nous, on ne l’avait même pas dans notre benchmark initial. On l’a découvert par sérendipité.

Le pivot n’est pas un échec, c’est la méthode. Tester vite, voir ce qui coince, ajuster. C’est ce qui fait la différence au vu de la vitesse à laquelle l’IA évolue aujourd’hui.

Les chiffres qui ont tout changé

Ces pivots successifs nous ont menés quelque part qu’on n’imaginait pas au départ. Il y a deux mois, on pensait que l’IA ne pouvait pas faire de vrais produits. Aujourd’hui, on en livre un par semaine.

Un projet récent pour un de nos clients a confirmé ce basculement. Une plateforme de gestion pour suivre des métriques métier en temps réel. Dashboard, backend, base de données, mise en production. Le type de projet qui mobilise habituellement plusieurs profils sur plusieurs mois.

Timeline classique : trois mois. Équipe classique : PM, designer, deux développeurs. Budget : plusieurs dizaines de milliers d’euros.

Résultat obtenu : sept jours, une personne, un dixième du coût.

Les chiffres :

• Temps : divisé par 12

• Équipe : divisée par 3

• Budget : divisé par 10

La qualité est restée équivalente parce que la personne qui pilotait savait cadrer et arbitrer. L’IA a démultiplié sa capacité d’exécution sans remplacer son expertise.

Sur les projets internes, même constat. En trois semaines, plus d’outils produits qu’en deux ans. Sans impact sur les missions en cours. Sans recrutement.

Ces projets ne dorment plus dans un backlog en attendant du temps ou une embauche. Ils avancent entre deux réunions. La contrainte “on n’a pas les ressources” a cessé d’être un blocage automatique.

Ce qui était structurellement impossible devient faisable.

Les questions à se poser maintenant

Ces chiffres qui étaient encore jusqu’ici impensables, viennent de changer l’équation économique du développement. Pas juste pour nous. Pour toute organisation tech.

Un projet qui représentait un investissement lourd devient accessible. Un délai qui imposait des arbitrages difficiles devient gérable. Une roadmap qu’on devait étaler se compresse.

Votre backlog est-il basé sur d’anciennes contraintes ?

Regardez les projets que vous avez mis de côté ces douze derniers mois. Combien d’entre eux sont en pause avec cette justification : “on n’a pas les ressources” ?

Ce calcul était valide il y a six mois. Il ne l’est probablement plus aujourd’hui. Quand une personne qui sait cadrer peut livrer ce qui nécessitait une équipe complète, la contrainte change de nature.

Ça ne signifie pas qu’il faut réduire les équipes. Ça signifie que ce qui était structurellement impossible devient faisable. Les projets qu’on ne lançait pas par manque de temps ou de budget méritent d’être réévalués.

Combien de temps avant que vos concurrents aient ces chiffres ?

Pendant que vous attendez que l’IA devienne plus mature, d’autres organisations testent. Elles accumulent des résultats similaires. Elles réallouent leurs ressources en conséquence.

L’écart se mesure déjà. Diviser ses coûts de développement par 3 à 10. Ou multiplier par 10 ce qu’on livre avec le même budget. Tester une hypothèse produit en une semaine au lieu de trois mois. Ce ne sont plus des projections, ce sont des faits mesurés.

Ceux qui attendent que l’IA “s’améliore” ne voient pas que d’autres ont déjà changé leur façon de travailler. L’écart ne va pas se résorber. Il va s’accentuer.

Par où commencer ?

La réponse est plus simple qu’elle n’y paraît. Le vrai défi n’est pas technique. Il est méthodologique.

Il faut savoir découper son métier en étapes suffisamment claires pour qu’un système puisse y contribuer. Identifier ce qui a de la valeur et ce qui n’en a pas. Définir ce qu’on garde et ce qu’on délègue. Établir les critères qui permettent de valider qu’un résultat est acceptable.

Si ce cadrage n’existe pas, l’IA ne le créera pas. Elle amplifie ce qui existe déjà. Un brief vague produira un résultat vague. Une vision structurée produira quelque chose d’utilisable.

Le coût d’attendre dépasse maintenant le coût de tester. Si vous pilotez encore avec les hypothèses d’il y a six mois, vous prenez probablement des décisions sur des bases périmées.

L’expérimentation continue

On ne s’arrête pas là. Cette expérimentation continue. On teste de nouveaux outils, on mesure de nouveaux cas d’usage, on accumule des learnings.

Dans les prochains mois, on va documenter d’autres aspects : comment on gère les erreurs d’agents IA en production, comment on mesure la qualité des outputs, comment on forme les équipes à piloter ces outils, les limites qu’on a rencontrées et comment on les contourne.

Ce qu’on a condensé ici, ce sont les trois premiers mois. Les bases. Ce qui permet de démarrer et d’éviter certains écueils.

Pour suivre la série en temps réel sur Linkedin et voir comment ça évolue, c’est ici que ça se passe.

La réalité ? Elle est probablement à 40%. Et vous mesurez les mauvaises choses.

Ce décalage n’est pas un problème de compétence. C’est un problème d’organisation et de communication entre CEO et CTO.

Quand le dirigeant ne voit pas ce qui se passe dans l’équipe, il imagine le pire.
Quand le CTO ne communique pas sur ce que fait son équipe, il crée un vide que le CEO remplit avec ses suppositions.

Voici comment sortir de ce piège.

Le vrai problème : vous ne voyez que ce qui sort

Vous comptez les features livrées, les tickets fermés, les sprints terminés. Mais qu’en est-il du reste ?

Une équipe peut passer des semaines sur de la dette technique sans rien livrer de visible. Elle travaille sur des choix d’architecture pris il y a deux ans qui ralentissent maintenant chaque développement. Les corriger ne produit rien à court terme, mais permet d’aller trois fois plus vite dans six mois.

Autre exemple : si votre application n’est pas stable, l’équipe passe une partie significative de son temps à résoudre des bugs en production. Ce temps n’apparaît nulle part dans vos métriques de vélocité.

Le travail invisible existe. Ne pas le voir ne signifie pas qu’il n’existe pas.

Le plafond des 90%

Même une équipe qui tourne au taquet ne dépasse jamais 90% de productivité.

Le plafond est là.

Pourquoi ? Parce que la tech n’est pas une chaîne de production. Il y a toujours quelque chose : un membre de l’équipe malade, une urgence client, un bug critique en production. Ces événements font partie d’un fonctionnement normal d’une équipe.

Si vous attendez que votre équipe soit à 100%, vous risquez d’être déçu et créer une pression contre-productive.

Comment mesurer vraiment

Oubliez les tickets et les story points pris isolément. Ils ne disent rien de la valeur produite.

Mesurez plutôt à quoi vous dépensez votre temps.

Voici le framework que nous utilisons avec nos clients :

Catégorisez le temps passé sur chaque activité de l’équipe :

• X% sur la résolution de bugs et la stabilisation

• X% sur la maintenance et l’amélioration technique

• X% sur les nouvelles fonctionnalités

• X% sur l’amélioration de la productivité (outillage, process, formation)

Quatre ou cinq catégories suffisent. Pas besoin de quinze sous-catégories que personne ne remplira.

Suivez l’évolution mois après mois :

• “Le mois dernier, 40% de notre temps partait en bugs. Ce mois-ci, on est à 25%.”

• “On passe 15% de notre temps sur l’amélioration de nos outils, ça commence à payer sur la vélocité.”

Cette cartographie change tout. Vous avez enfin des chiffres pour discuter.

Faut-il investir davantage dans la stabilisation ? Ralentir les nouvelles features pour rembourser de la dette technique ?

Ces questions deviennent actionnables.

Une responsabilité partagée

Côté CEO

Donner une vision claire au-delà de 3 mois

Sans roadmap partagée, c’est le chaos. Les priorités changent chaque semaine, l’équipe passe son temps à jongler entre des sujets qui n’aboutissent jamais.

Participer aux arbitrages

Quand vous demandez une nouvelle feature en urgence, qu’est-ce qu’on décale ? Cette question doit être posée explicitement avec le CTO, pas décidée dans le vide.

Accepter que la tech ≠ production industrielle

Vous ne pouvez pas changer les priorités chaque semaine sans impacter la productivité. Si vous voulez de la prévisibilité, donnez de la stabilité.

Côté CTO

Mesurer et communiquer la répartition du temps

Montrez concrètement sur quoi l’équipe travaille. Un tableau simple avec les grandes catégories suffit.

Rendre visible le travail invisible

Le CEO ne comprend pas forcément la dette technique ou le refactoring. Traduisez-le en impact business : “On a passé deux semaines sur cette refonte, ça va nous permettre de livrer les prochaines features 50% plus vite.”

Mettre en place des rituels d’alignement

Un call mensuel ou hebdomadaire avec votre CEO pour échanger sur la charge, les projets, les tensions. L’objectif : arbitrer avant que ça devienne un problème.

Par où commencer ?

Voici trois premières actions concrètes que vous pouvez mettre en place dès demain :

1. CTO : catégorisez le temps de votre équipe cette semaine

Bugs, maintenance technique, nouvelles features, amélioration productivité. Quatre colonnes, des pourcentages approximatifs. Ça prend 30 minutes.

2. CEO et CTO : bloquez un créneau mensuel d’une heure

Pour échanger sur la charge, les projets, ce qui coince. Ce rendez-vous devient non négociable.

3. Partagez une roadmap au-delà de 3 mois

Pas besoin d’un planning au jour près. Une direction claire avec les chantiers prioritaires suffit.

Ces trois actions ne règlent pas tout. Mais elles créent les conditions pour que CEO et CTO parlent enfin le même langage.

Le décalage de perception entre CEO et équipe tech vient rarement d’un problème de qualification. Il vient généralement d’une absence de mesure et de communication.

Quand vous savez sur quoi l’équipe passe son temps, et que vous avez une gouvernance claire pour arbitrer, vous voyez enfin l’efficience de votre équipe telle qu’elle est réellement.

Six mois plus tard, vous passez vos journées en réunions pour aligner tout le monde.

C’est une simple question de maths.

À 3 personnes, il y a 3 relations possibles. À 10, il y en a 45. À 30, on dépasse les 400.

Plus votre équipe grandit, plus sa complexité explose, sans que votre capacité à coordonner ne change.

Résultat : vous passez plus de temps à expliquer, répéter, aligner, qu’à produire.

Pendant ce temps, votre concurrent à 8 personnes itère deux fois plus vite. Pas parce qu’il est meilleur. Parce qu’il n’a pas à gérer 400 relations.

La tech est en train de sortir du dogme “lever = recruter massivement”. Les boîtes qui performent aujourd’hui restent en mode commando. 5 à 15 personnes max par équipe. Elles avancent pour construire, pas pour coordonner.

On parle de ce basculement dans cette vidéo.

👋 Bonjour,

Ce mois-ci, on vous a sélectionné 6 ressources pour :

• Comprendre pourquoi l’IA échoue dans la plupart des entreprises qui ont du legacy

• Passer du POC qui s’éternise au déploiement qui apparaît dans le P&L

• Voir ce que ça donne concrètement, chez des boîtes qui l’ont traversé

• Reprendre la main sur votre propre transformation, en tant que CEO

La vraie question à vous poser en 2026 : vous n’êtes pas en train de lancer une startup from scratch, vous avez un existant, des équipes, du code, des process, des habitudes.

Alors comment intégrer l’IA dans ce contexte-là, avec ces contraintes-là ?

Pas de hype, pas de concepts abstraits : que du concret pour les dirigeants qui pilotent une transformation IA sur un terrain déjà occupé.

🗞️ Les articles du mois

1. Ce que les boards attendent vraiment de vous sur l’IA en 2026

→ Lire : What leaders need to get right in 2026 – Insight Partners

Les pilotes IA, les dashboards d’adoption, les POC qui s’enchaînent sans suite. En 2026, les boards n’en veulent plus. La question est devenue simple : est-ce que ça apparaît dans le P&L, ou pas ?

Insight Partners le voit sur +800 boîtes en portefeuille : l’IA doit maintenant justifier sa ligne dans le budget, pas juste sa place dans la roadmap.

✅ Pourquoi le lire ?

Cet article compile les observations de six Managing Directors et Operating Partners qui passent leurs semaines dans des boards de scale-ups. Ce n’est pas de la recherche académique, c’est ce qui se dit réellement en comité de direction.

Quelques points qui méritent qu’on s’y arrête :

• Les entreprises qui avancent vraiment sur l’IA sont celles qui avaient déjà des fondations solides : data propre, process définis, organisation cohérente. Pablo Dominguez le dit autrement : “L’IA ne va pas remplacer ce que vous n’avez jamais eu.”

• La question qui dérange : “Imaginez que vous lanciez une nouvelle entreprise pour détruire la vôtre, avec l’IA et sans dette technique. Que feriez-vous ? Parce que c’est ce que font vos concurrents en ce moment.”

• Des objectifs chiffrés concrets, rarement publiés : entre 2 et 5 points de marge récupérables via l’IA, répartis entre le marketing, la R&D et le customer success.

• Ce que ça change pour le profil CEO : l’expertise technique devient attendue à tous les niveaux de la direction. Pas pour coder, mais pour avoir un avis, challenger, arbitrer.

💡 À retenir : “Les entreprises qui pensent que l’IA va compenser ce qu’elles n’ont jamais su faire vont souffrir.”

2. Pourquoi la plupart des déploiements IA en entreprise n’aboutissent pas

→ Lire : The Hard Truth About Enterprise AI Adoption – Bain Capital Ventures

“95% des POC IA échouent.” Ce chiffre a fait le tour des boardrooms en 2025. La réalité est moins spectaculaire et plus instructive : les modèles évoluent bien plus vite que les organisations. C’est là que ça coince, pas dans la technologie.

Cet article publié en février 2026 documente une année de déploiements IA dans des grandes entreprises établies, avec des noms, des détails, et une conclusion qui dérange.

✅ Pourquoi le lire ?

American Express a dû stopper son déploiement IA et reconstruire entièrement sa couche data avant de pouvoir avancer. Pas parce que le modèle était mauvais. Parce que la donnée en dessous était inconsistante, incomplète, non gouvernée. Une fois les fondations refaites, l’outil s’est déployé sur 19 marchés. Quand Duolingo a communiqué sur l’IA sans clarifier l’impact sur les rôles, le résultat n’a pas été de l’adoption. C’est de la résistance organisée.

Ce que font les entreprises qui s’en sortent : elles écrivent la métrique cible avant de choisir le modèle. Le template proposé dans l’article est directement utilisable en réunion de direction : “Pour améliorer [métrique] de [X%] pour [équipe] d’ici [date], nous allons [use case].” Si vous ne pouvez pas remplir tous les blancs, vous faites encore un prototype.

💡 À retenir : “Don’t bolt a rocket to a horse cart.”

3. Du “bolt-on” au “built-in” : le framework pour les entreprises qui ont un existant lourd

→ Lire : How Legacy Companies Can Become AI-Enabled – HR Executive

Il y a une différence entre greffer l’IA sur des process existants pour aller un peu plus vite, et refondre ces process en utilisant l’IA comme levier de redesign. La première approche représente ce que font 85% des entreprises aujourd’hui. La deuxième est ce qui crée de la valeur visible sur le compte de résultat.

L’Institute for Corporate Productivity a interrogé près de 300 entreprises de plus de 1 000 salariés. Ce qu’ils trouvent : seulement 15% ont vraiment passé le cap. Les 85% restants pilotent une AI dans du vieux monde.

✅ Pourquoi le lire ?

Parce que l’article nomme un problème systémique que peu de dirigeants voient depuis leur position.

Dans une entreprise, un commercial a développé une technique IA pour automatiser une partie de son process de vente. Ses résultats s’envolent. Il garde la méthode pour lui, parce que le système d’incentive traditionnel l’y pousse. L’entreprise a investi dans l’IA. Le gain est resté individuel. C’est le “bolt-on” en action : l’outil change, le cadre organisationnel autour reste identique, et les gains ne se diffusent pas.

Des cas concrets que l’article documente : WPP a réduit 50 000 intitulés de postes à 6 000 en repassant par l’IA l’ensemble de sa taxonomie métiers. L’US Army met à jour 300 000 fiches de personnel en une semaine. Moderna a construit plus de 3 000 GPTs internes intégrés à toute sa chaîne de valeur, de la conception du médicament jusqu’aux RH.

Le framework en six étapes proposé (prioriser les fonctions à fort impact, décomposer le travail en tâches, prototyper, diagnostiquer les gaps de compétences et de data, aligner les systèmes, scaler et itérer) est l’un des plus rigoureux de ce qui a été publié sur le sujet.

💡 À retenir : “Arrêtez de greffer. Faites exploser certaines choses. Avec une feuille blanche, construisez la meilleure façon d’obtenir non pas les mêmes résultats, mais de meilleurs.”

4. L’IA, c’est votre boulot. Pas celui de votre CTO.

→ Lire : CEO, AI Is Your Job – Forbes / Sylvain Duranton, BCG

72% des PDG déclarent être désormais les principaux décideurs sur l’IA dans leur organisation. C’est deux fois plus qu’en 2025. La vague agentique a changé la perception du risque : les enjeux sont trop larges pour rester dans un silo tech.

Sylvain Duranton, Senior Partner BCG X, s’appuie sur une étude menée auprès de 2 300 dirigeants pour poser une conclusion simple : la stratégie IA ne se délègue plus.

✅ Pourquoi le lire ?

Parce que c’est l’article qui pose la question à laquelle tout le reste de cette édition répond : qui tient réellement le gouvernail ?

Un dirigeant sur deux estime que sa longévité dans le rôle dépend de sa capacité à faire de son entreprise un “AI champion”. En moyenne, les dirigeants prévoient de doubler leurs ressources IA en 2026. Dans l’assurance, l’énergie et le consumer goods, l’objectif est de les tripler.

Ce que l’étude pointe, et que peu d’articles osent dire franchement : les CEOs sont convaincus de l’urgence. Les membres de leur comex le sont deux fois moins. C’est là que se jouent la plupart des transformations qui n’aboutissent pas. Pas dans le choix du modèle IA, pas dans le budget alloué. Dans l’écart de conviction entre le dirigeant et son équipe de direction.

💡 À retenir : “La stratégie IA n’est plus un sujet à déléguer. Et les CEO qui attendent que ça se fasse tout seul prennent un risque stratégique qui va croissant.”

🎬 L’espace média

Comment Airtable a réorganisé toute l’entreprise autour de l’IA

→ Regarder : How we restructured Airtable’s entire org for AI – Lenny’s Podcast (~1h30)

Un tweet viral annonce qu’Airtable est mort. Les données sont fausses, mais la pression est réelle. Howie Liu, co-founder et CEO d’Airtable (valorisée ~12 milliards de dollars), ne répond pas au tweet. Il réorganise l’entreprise.

✅ Pourquoi le regarder ?

C’est le témoignage d’un CEO de scale-up tech qui raconte exactement ce qu’il a modifié dans son organisation. Pas un plan de transformation sur 3 ans. Ce qui a changé, comment, et pourquoi.

Howie Liu a instauré deux types d’équipes qui fonctionnent à des vitesses différentes, une pour shipper des features IA chaque semaine, une autre pour tenir la stratégie à moyen terme. L’idée vient de Kahneman (Système 1 / Système 2), appliquée à une org chart. Il est aussi le premier utilisateur IA d’Airtable en termes de coût d’inférence. Il n’a pas délégué le sujet.

Sa décision la plus contre-intuitive : demander à ses équipes d’annuler toutes leurs réunions pendant une semaine pour simplement explorer les outils IA. Sans objectif de delivery, sans compte-rendu attendu. L’exploration comme directive. Et pourquoi les métriques d’évaluation peuvent parfois tuer l’innovation avant qu’elle commence.

💡 À retenir : “Dans l’ère de l’IA, les CEO doivent redevenir des contributeurs individuels. Si vous vous éloignez des détails que vous aimez, vous perdez la capacité à piloter.”

Comment AXA France a industrialisé l’IA sur un existant lourd

→ Regarder : L’AI/GenAI Factory : un modèle gagnant pour AXA France – Artefact (~15 min)

AXA France c’est : des milliers de collaborateurs, des process historiques, une réglementation contraignante, un EU AI Act à intégrer. Et un assistant IA interne déployé en production en 3 semaines.

Hugo Hamad, Head of AI Factory chez AXA France (passé par Decathlon dans le même rôle), explique ce qui a rendu ça possible.

✅ Pourquoi le regarder ?

Là où Howie Liu parle depuis une scale-up tech agile, Hugo Hamad parle depuis exactement les contraintes que connaissent la plupart des entreprises établies : dette technique, gouvernance distribuée, cadre réglementaire.

Le modèle qu’il décrit, l’AI Factory, repose sur trois fonctions distinctes : des équipes delivery intégrées aux métiers, une équipe plateforme qui construit des socles réutilisables “prêts à l’emploi”, et une équipe gouvernance qui s’assure que tout ce qui sort respecte les exigences de l’EU AI Act et les principes de sécurité dès la conception.

Ce qui est intéressant dans son raisonnement : industrialiser correctement l’approche IA dès le départ, c’est répondre automatiquement à la quasi-totalité des exigences réglementaires. La gouvernance n’est pas une contrainte subie en fin de projet. C’est ce qui permet d’aller vite en toute sécurité, et de le reproduire.

💡 À retenir : “Quand on fait les choses by design, la réglementation n’est plus un frein. Elle devient le cadre qui accélère.”

À très vite,

— L’équipe Hones

Pas de ralentir ou de pivoter. D’arrêter.

Parce que quand vous êtes trop loin dans les récifs, redresser la barre coûte souvent plus cher que de construire un nouveau bateau.

C’est l’une des décisions les plus difficiles à formuler. Et pourtant, c’est parfois la plus honnête qu’on puisse donner.

Dans cette vidéo, Matthieu revient sur les situations critiques qu’on rencontre chez Hones : les projets qu’il vaut mieux abandonner, et les moments où une séparation dans l’équipe technique devient inévitable pour protéger la société.

Ce n’est pas la partie la plus glamour du conseil. Mais c’est là, souvent, que se jouent les vraies décisions.

👋 Bonjour,

Ce mois-ci, on vous a sélectionné 3 ressources pour :

• Comprendre pourquoi l’IA est devenue un sujet de direction générale

• Identifier ce qui distingue les entreprises qui créent de la valeur de celles qui accumulent les POC

• Évaluer votre propre posture de dirigeant face à cette transformation

• Passer du “il faut faire de l’IA” au “voilà comment je pilote”

La vraie question pour un CEO en 2026 : qu’est-ce que ça change concrètement dans ma manière de piloter ? Prise de décision, relation avec les équipes tech, arbitrages stratégiques, gouvernance. Le sujet n’est plus technologique. Il est managérial.

Pas de bullshit, pas de concepts abstraits : que du concret pour les dirigeants qui veulent piloter cette transformation, pas la subir.

🗞️ Les articles du mois

1. Les CEO prennent le contrôle de la stratégie IA : ce que révèle l’étude BCG 2026

→ Lire : Un PDG sur deux estime que sa réussite dépend de sa stratégie IA

Il y a un an, l’IA était encore un sujet délégué aux équipes tech. En 2026, la donne a changé : 72% des PDG déclarent être désormais les principaux décideurs en matière d’IA. C’est deux fois plus qu’en 2025.

Ce n’est plus une tendance. C’est un basculement.

✅ Pourquoi le lire ?

Cette étude BCG, menée auprès de 2 360 dirigeants dans le monde (dont 640 PDG), pose un constat qui devrait interpeller tout CEO de startup ou scale-up : la stratégie IA n’est plus un sujet à déléguer. Elle engage directement votre capacité à piloter l’entreprise.

Quelques chiffres qui méritent qu’on s’y arrête :

• Les entreprises prévoient de doubler leurs dépenses IA en 2026 (1,7% du CA en moyenne).

• 94% des PDG maintiendront ce niveau d’investissement même sans ROI immédiat.

• Les PDG “pionniers” consacrent 60% de leur budget IA à la formation, contre 27% chez les pragmatiques.

Ce que montre cette étude, ce n’est pas que l’IA devient importante. C’est que la capacité d’un CEO à piloter sa transformation IA devient un critère de performance. Et les dirigeants qui restent en retrait sur ce sujet prennent un risque stratégique croissant.

La bonne nouvelle pour les dirigeants français : 42% des PDG hexagonaux sont classés “pionniers”, ce qui place la France en tête des pays européens. La mauvaise nouvelle : cela signifie aussi que 58% ne le sont pas.

💡 À retenir : “L’IA n’est plus un sujet tech. C’est un sujet de direction générale. Les CEO qui ne s’en emparent pas perdent la main sur leur propre vélocité.”

2. Stratégie IA en scale-up : pourquoi 2026 marque un point de bascule

→ Lire : Stratégie IA en scale-up : pourquoi 2026 sera décisive

Le vrai risque de l’IA pour une scale-up n’est pas que les développeurs soient remplacés. C’est l’écart de vélocité qui se creuse, chaque jour un peu plus, entre les entreprises qui structurent leur adoption et celles qui improvisent.

Cet écart ne se rattrape pas avec un budget ou une embauche. Il se rattrape avec une stratégie.

✅ Pourquoi le lire ?

Cet article pose un diagnostic frontal sur la situation des entreprises françaises face à l’IA. Les chiffres parlent d’eux-mêmes : 60% des PME sont encore au niveau 1 d’adoption, c’est-à-dire un usage non cadré, sans objectifs définis, sans équipes formées. Autrement dit, elles utilisent l’IA. Mais elles n’ont pas de stratégie IA.

La nuance est fondamentale. Et les conséquences commencent à se matérialiser.

Ce que montre l’article :

• L’écart de vélocité entre entreprises IA-structurées et les autres suit une courbe exponentielle, pas linéaire.

• Le retard français n’est pas un problème de moyens ou d’accès aux outils. C’est un problème de gouvernance.

• L’IA amplifie ce qui existe. Une organisation qui dysfonctionne ira plus vite, droit vers le mur.

L’article propose aussi 5 actions concrètes pour structurer une stratégie IA : résoudre les problèmes de gouvernance d’abord, désigner un responsable avec un mandat clair, formaliser un plan avec des objectifs mesurables, former avant d’outiller, mesurer et itérer.

Pour un CEO de scale-up, c’est une lecture qui remet les priorités dans l’ordre. La question n’est plus “faut-il adopter l’IA ?”. Elle est : “mon organisation est-elle structurée pour accélérer, ou pour amplifier ses propres faiblesses ?”

💡 À retenir : “L’IA est un révélateur. Elle ne crée pas les problèmes d’une organisation. Elle les expose et les amplifie.”

3. 78% des grandes entreprises utilisent l’IA en production. Le ROI reste décevant.

→ Lire : Leaders, gainers and unexpected winners in the Enterprise AI arms race

OpenAI, Anthropic, Google, Microsoft… La guerre des modèles fait rage. Les budgets explosent. Les CIOs empilent les fournisseurs.

Mais quand a16z interroge 100 décideurs du Global 2000 sur leurs résultats concrets, le constat est plus nuancé : le ROI réel “ne correspond pas au discours ambiant”.

✅ Pourquoi le lire ?

Cette étude annuelle d’Andreessen Horowitz auprès des plus grandes entreprises mondiales offre une photo nette du marché IA enterprise. Au-delà des parts de marché (OpenAI à 78%, Anthropic en forte progression), ce sont les constats de fond qui méritent l’attention.

Ce que révèle l’enquête :

• 81% des entreprises utilisent désormais 3 fournisseurs de modèles ou plus. La fragmentation s’accélère.

• 65% préfèrent les solutions des éditeurs historiques (Microsoft en tête). Pas pour la technologie. Pour la confiance, l’intégration existante et la simplicité d’achat.

• Le budget IA moyen bondit de 65% cette année. Mais les gains mesurés restent en-deçà des attentes.

Pour un CEO, cette étude rappelle une évidence souvent oubliée : le choix de l’outil compte moins que la capacité de l’organisation à l’absorber. Les entreprises qui captent de la valeur ne sont pas celles qui ont les meilleurs modèles. Ce sont celles qui ont d’abord travaillé sur le facteur humain.

💡 À retenir : “Les entreprises apprennent encore à déployer l’IA efficacement. Et elles ne savent pas à quoi ressemble le ‘bon’ tant qu’elles ne l’ont pas expérimenté.”

🎧 L’espace média

Podcast : L’optimisme méthodique d’un CTO face à l’IA

→ Écouter : De la Silicon Valley à Alan : l’optimisme méthodique du CTO face à l’IA et l’humain – Tech.Rocks (27 min)

80% des utilisateurs d’Alan préfèrent parler à l’IA plutôt qu’à un humain. Parce que l’IA est jugée plus empathique : toujours disponible, toujours patiente.

Ce chiffre vient de Charles Gorintin, cofondateur et CTO d’Alan, dans cet échange avec Julien Jouhault (CTO leboncoin).

✅ Pourquoi l’écouter ?

Après les grandes études et les conseils de cabinets internationaux, ce podcast ramène le sujet sur le terrain. Un CTO français, passé par Facebook, Instagram et Twitter, qui partage ce qu’il a appris en construisant une scale-up de 500 personnes.

Ce qui ressort de l’échange :

• Sa philosophie de leader : “se virer de son boulot tous les 6 à 12 mois” en recrutant des gens meilleurs que soi. Une organisation qui ne se renouvelle pas se fige.

• Son regard sur l’IA : elle ne remplace pas l’humain, elle nous libère des tâches ingrates pour qu’on puisse être plus humains là où ça compte.

• Son concept d’optimisme méthodique : ni naïveté, ni attentisme. Agir concrètement, tester, mesurer, ajuster. C’est comme ça qu’Alan a mis en production un assistant IA que les utilisateurs préfèrent au chat humain.

Pour un dirigeant, c’est une invitation à sortir du débat théorique “l’IA va-t-elle remplacer les emplois ?” pour entrer dans une question plus utile : comment je structure mon organisation pour que l’IA amplifie ce qu’on fait de mieux ?

💡 À retenir : “L’IA va nous permettre d’être plus humains en nous libérant des tâches ingrates.”

Podcast : How the best CEOs are meeting the AI moment

→ Écouter : How the best CEOs are meeting the AI moment

“C’est 80% transformation business et 20% transformation tech.”

Cette phrase d’Eric Kutcher résume à elle seule pourquoi tant d’entreprises peinent à voir un ROI sur leurs investissements IA. Elles traitent l’IA comme un projet tech. C’est une erreur de cadrage.

✅ Pourquoi l’écouter ?

Ce podcast ne parle pas d’outils ou de modèles. Il parle du rôle du CEO face à ce qu’Eric Kutcher appelle le “legacy moment” : le moment où un dirigeant définit ce que sera son héritage.

Son constat est sans appel : les CEOs qui s’emparent du sujet transformeront leur organisation. Ceux qui attendent ne survivront pas. “It’s that binary.”

Ce qui distingue les meilleurs selon lui :

• Ils ne déploient pas l’IA en espérant que “de bonnes choses arrivent”. Ils réimaginent leurs process.

• Ils développent leur propre fluency IA. Pas en lisant des rapports, mais en passant du temps avec les équipes qui utilisent la technologie au quotidien.

• Ils osent être vulnérables. Dire “je ne sais pas” n’est plus une faiblesse. C’est ce qui permet d’apprendre.

Un point qui mérite qu’on s’y arrête : l’organisation du futur sera plus plate. “Way more workers and judgment, way fewer managers.” Ce n’est pas juste une évolution des outils. C’est une remise en cause des structures de management.

Pour un CEO de scale-up, ce podcast est une invitation à se poser la vraie question : est-ce que je pilote cette transformation, ou est-ce que je la délègue en espérant qu’elle se fasse toute seule ?

💡 À retenir : “The CEOs who take this on will take their organizations to a different level. And CEOs who sit and wait—their companies aren’t going to exist.”

👥 Deux profils de CEO face à l’IA

Dans quelle colonne vous reconnaissez-vous le plus souvent ? La réponse en dit long sur votre posture face à cette transformation.

À très vite,

— L’équipe Hones