L'IA n'invente pas l'expertise : elle l'amplifie

L'IA n'invente pas l'expertise : elle amplifie celle que vous lui apportez. Sur les sujets que je maîtrise, les résultats font un saut net ; sur les sujets adjacents, le gain est réel mais bien plus modeste. Ce constat de terrain, répété tous les jours depuis que je travaille avec des agents IA, a des conséquences directes sur la façon dont on compose, recrute et évalue les équipes. Voici lesquelles.

Depuis que je travaille tous les jours avec des agents IA, j'ai un constat qui revient sans arrêt : la qualité de ce que je produis avec une IA dépend très peu du modèle utilisé, et beaucoup de mon niveau d'expertise sur le sujet traité. C'est en regardant ce constat sous un autre angle qu'on commence à voir comment l'IA va transformer la collaboration dans nos organisations.

Sur les sujets que je maîtrise vraiment, les résultats sont extraordinaires

Quand je pilote une IA sur des décisions d'architecture technique, la conception d'un harnais de tests E2E, ou la revue d'une stratégie de déploiement, les résultats sont d'une qualité que je n'aurais jamais imaginée il y a deux ans. Je ne parle pas de gain de productivité de 10 %. Je parle d'un saut net.

Pourquoi ? Parce que je fais du développement depuis vingt ans, que je pilote des équipes tech depuis quinze ans. Quand l'IA me propose une option, je sais immédiatement si elle est bonne, si elle a un défaut subtil, ou si elle passe à côté d'un cas que mon expérience me souffle. Je ne lui demande pas seulement de coder : je lui demande de choisir entre dix manières de coder, et je choisis avec elle. C'est un pilotage d'expert.

Sur les sujets adjacents, le saut qualitatif est moins spectaculaire

Le contraste est net quand je prends un sujet où je ne suis pas expert.

Quand je pilote une IA sur la conception d'un parcours marketing, sur la déclinaison d'un design system, sur le copywriting d'une page de prestation, le résultat reste bon. Très probablement meilleur, et plus rapide, que ce que la majorité des praticiens (même expérimentés) produiraient à la main dans le même temps. Mais le saut qualitatif que je constate sur mes sujets d'expertise n'est plus le même. Je me contente plus souvent de la première proposition de l'IA, parce que je n'ai pas les références fines pour savoir quand pousser plus loin et quand m'arrêter.

Et quand je rebascule ce travail vers d'anciens collègues de Wizbii qui sont, eux, vraiment experts en marketing ou en design (quand ils me donnent leur vocabulaire, leurs insights, leur intuition métier), le résultat fait à nouveau un saut. Pas parce que l'IA est devenue meilleure entre-temps. Parce que le pilotage est devenu plus expert.

Ce que ça révèle

L'IA n'invente pas l'expertise. Elle amplifie celle qu'on lui apporte.

Un expert qui pilote une IA produit ce que cet expert produirait s'il avait dix mains, dix cerveaux, et zéro fatigue. Un non-expert qui pilote la même IA produit la moyenne de ce que dit Internet sur le sujet : un travail honnête, parfois utile, jamais distinctif.

Concrètement, ce que l'expertise change dans le pilotage tient en quelques gestes que le non-expert ne peut tout simplement pas poser :

• Savoir quand s'arrêter. L'expert reconnaît une bonne réponse du premier coup ; le non-expert ne sait pas si la proposition est excellente ou médiocre, et se contente donc de la première.
• Repérer le défaut subtil. Une option qui « a l'air » correcte mais qui cassera dans six mois, l'expert la sent ; l'IA ne la signale pas spontanément.
• Challenger la direction. L'expert reformule, redirige, impose une contrainte que l'IA n'avait pas anticipée. C'est là que naît la qualité distinctive.
• Apporter le vocabulaire métier. Les bons mots-clés, les bons critères, les cas particuliers : c'est ce carburant que l'IA n'a pas et que seul un praticien fournit.

Le contraste se voit le plus nettement quand on compare deux résultats produits avec le même modèle, le même jour, sur le même sujet : la différence ne vient jamais de l'outil, toujours de la main qui le tient.

C'est en partant de ce constat que j'ai progressivement compris que la promesse parfois entendue d'une « IA qui remplace les experts » se trompe. L'IA ne remplace pas les experts : elle augmente énormément leur valeur, et elle réduit énormément la valeur de ceux qui n'avaient pas d'expertise propre à apporter.

Conséquence pour nos organisations : la fin des silos d'expertise

Avant l'IA, pour qu'un développeur bénéficie de l'expertise marketing de l'organisation sur un projet, il fallait organiser une réunion. Faire passer du contexte. Attendre que la collègue marketing soit dispo. Recommencer si une question surgissait trois jours plus tard. La friction était énorme, et elle expliquait pourquoi tant de projets sortaient sans la qualité d'expertise dont l'entreprise disposait pourtant en interne.

Avec l'IA, la mécanique change. C'est exactement le sujet que j'ai détaillé dans Le monorepo-mémoire : le vrai levier n'est pas le prompt. Chaque expert dépose son contexte (son vocabulaire, ses critères, ses cas particuliers, ses non-négociables) une fois, dans la mémoire vivante du projet. Toute l'organisation peut ensuite mobiliser cette expertise via l'IA, à n'importe quel moment, sans sortir l'expert d'une autre tâche.

Et ce dépôt de contexte n'est pas réservé aux développeurs. C'est même la condition pour que les silos tombent vraiment : un responsable marketing, un juriste ou un financier doit pouvoir transmettre son expertise à la mémoire commune sans écrire une ligne de code. J'explique comment faire concrètement dans partager la mémoire d'un projet Git quand on n'est pas développeur : parce qu'une expertise qui reste dans la tête d'une seule personne ne profite à personne d'autre, et qu'on ne peut pas demander à chaque expert d'apprendre Git pour participer.

Concrètement, ça veut dire qu'une décision d'architecture technique peut intégrer en cinq minutes le point de vue marketing, design, juridique et financier de l'organisation : pas parce que l'IA fait du bon travail dans chacun de ces domaines toute seule, mais parce qu'elle a accès à ce que chaque expert a déposé. C'est un gain de coordination dont nos organisations n'ont jamais bénéficié auparavant.

Pour les équipes tech qui veulent installer cette dynamique, j'ai détaillé l'approche dans Déployer l'IA agentique dans une équipe de 40 personnes, et plus largement dans Les nouveaux rôles dans une équipe tech augmentée par l'IA.

Ce qui se complique : la place du non-expert

Le revers de la médaille est moins facile à dire, mais il faut le poser honnêtement. Si l'IA amplifie l'expertise de ceux qui en ont, elle réduit mécaniquement la valeur ajoutée de ceux qui apportaient surtout leur temps disponible plutôt qu'une expertise propre.

Je pense aux profils intermédiaires qui faisaient le lien entre les experts, qui synthétisaient, qui rédigeaient ce que d'autres pensaient. Ces tâches deviennent les premières que l'IA prend en charge correctement, pas brillamment, mais correctement, et à un coût marginal proche de zéro. Les organisations qui s'organisaient avec une couche épaisse d'intermédiaires vont sentir la pression la plus forte.

Ce n'est pas une fatalité. Le chemin est de devenir expert sur quelque chose. L'expertise n'est pas une question de diplôme, c'est une question de pratique répétée et d'intuition métier accumulée. Tout collaborateur a un domaine où il peut se positionner comme l'expert de l'organisation, à condition de l'identifier et de le travailler activement.

Donc, qu'est-ce qui change pour les équipes ?

Les équipes ne disparaissent pas. Elles changent de nature.

L'équipe d'avant l'IA était structurée autour d'une logique de coordination : on découpait le travail entre généralistes pour avancer en parallèle, et on se synchronisait régulièrement pour réintégrer les morceaux. L'équipe avec l'IA se structure autour d'une logique d'orchestration : chaque membre apporte une expertise distinctive, qu'il dépose dans la mémoire commune et qu'il pilote activement quand son domaine est sollicité.

Ce n'est pas un détail organisationnel. C'est un changement de ce qui fait la valeur d'une équipe, et donc de qui la compose, comment on la recrute, comment on l'évalue, comment on la forme. Les CTO et les CPO qui prennent ce virage sérieusement le constatent vite : les équipes plus petites mais plus expertes battent largement les équipes plus grandes mais plus généralistes.

Piloter un projet de dev avec l'IA quand on n'est pas technique

Oui, c'est à votre portée. Vous ne codez pas, mais vous décidez : ce que l'IA produit reflète la clarté de ce que vous lui apportez. Votre rôle de fondateur non-tech, c'est de fournir le contexte métier, d'arbitrer les options et de poser les critères de « fini ». L'IA fait le reste.

Le piège, quand on débute, c'est de croire qu'il faut comprendre le code pour piloter. Faux. Ce qui compte, c'est de savoir ce que vous voulez et de le formuler avec assez de précision. Concrètement, quelques gestes de pilotage sont à votre portée immédiate, sans une ligne de code :

• Décrire le problème, pas la solution technique. « Mes clients abandonnent au paiement » est un bien meilleur point de départ que « ajoute un bouton Stripe ». Vous êtes l'expert de votre marché, pas du framework : tenez votre côté.
• Exiger une démo, pas un rapport. Ne demandez pas « est-ce que c'est fait ? », demandez à voir la chose marcher devant vous. Une fonctionnalité qu'on ne peut pas montrer n'est pas finie.
• Poser le critère de « réussi » avant de lancer. « Ce sera bon quand un utilisateur pourra s'inscrire et recevoir son email de confirmation en moins de deux minutes. » Sans ce critère, ni vous ni l'IA ne savez quand vous arrêter.
• Déposer votre contexte métier une fois. Votre vocabulaire, vos cas particuliers, vos non-négociables réglementaires : écrits une fois dans la mémoire du projet, ils nourrissent chaque tâche suivante. C'est ce que je détaille dans le guide complet sur l'IA agentique.

Ce que vous n'aurez pas, c'est l'œil de l'expert sur la qualité technique invisible (l'architecture qui tiendra à dix mille utilisateurs, le défaut de sécurité qui ne se voit pas à l'écran). Ce point me mène à la question d'après.

L'IA peut-elle remplacer un CTO ou un développeur en startup ?

Non, pas en 2026, et je le dis sans hype. L'IA déplace la vélocité : ce qui prenait des semaines de code prend des jours. Mais elle ne déplace pas la décision d'architecture, l'arbitrage des risques, ni la responsabilité de ce qui part en production. Ces parts-là restent humaines.

Soyons précis sur ce qui bouge et ce qui ne bouge pas. Ce que l'IA prend en charge, vraiment : écrire le code, le tester, le documenter, explorer dix variantes d'une fonctionnalité en une après-midi, faire le travail d'un développeur junior à coût marginal proche de zéro. Sur ce terrain, un fondateur qui pilote bien va plus vite qu'une petite équipe d'il y a deux ans.

Ce qui reste humain, et ne se délègue pas :

• L'architecture qui engage l'avenir. Choisir une fondation technique, c'est arbitrer entre time-to-market, coût et scalabilité futures. L'IA propose ; quelqu'un qui en a vu casser doit trancher.
• La responsabilité de la production. Quand un paiement échoue ou qu'une donnée fuite, ce n'est pas l'IA qui répond devant vos clients. La décision de mettre en ligne porte un nom.
• Le jugement sur le « bon assez ». Savoir quand un sujet mérite qu'on s'acharne et quand la première solution suffit : c'est de l'expérience accumulée, pas une réponse de modèle.

Donc le CTO n'est pas remplacé, mais son rôle se déplace : moins de mains sur le clavier, plus de décisions d'architecture et de pilotage de l'IA. La vraie question, pour un fondateur, n'est pas « IA ou CTO », c'est « à partir de quel moment ce jugement me manque-t-il assez pour le recruter ». J'y réponds dans quand recruter un CTO en startup.

Structurer cette dynamique dans votre équipe

Aider les CTO et directions tech à passer d'une équipe « coordonnée » à une équipe « d'experts qui pilotent l'IA »,
c'est précisément ce que je fais en accompagnement IA agentique. Audit de
la situation actuelle, plan d'évolution réaliste, mise en place du monorepo-mémoire et formation des équipes.