5 schémas courants qui entraînent des échecs de l’IA

Adam Horner a constitué des équipes d’ingénierie dans la fintech et les logiciels d’entreprise. Il est désormais le fondateur de The CTO Playbook, où il forme et intervient comme CTO fractionné.

Nous nous sommes entretenus avec lui pour comprendre les tendances qu'il observe sous les succès et échecs de l’intégration de l’IA. Voici ce qu’il nous a confié.

Une version différente du même défi

Je suis Adam Horner, coach CTO et CTO fractionné chez The CTO Playbook. J’ai passé le début de ma carrière comme ingénieur puis CTO cofondateur, en construisant et pilotant des équipes d’ingénierie dans la fintech et les logiciels d’entreprise, dont plusieurs années chez Palantir où j’ai été l’un des premiers recrutés au Royaume-Uni.

Ma transition vers le coaching est venue d’une observation simple : Devenir un dirigeant technologique efficace est vraiment difficile, et la plupart avancent sans feuille de route ni allié ayant déjà vécu cette expérience. C’est ce que je fais aujourd’hui, aider les CTOs à franchir ce que j’appelle le fossé du CTO.

L’aspect IA, pour moi, n’est pas une ligne séparée. Il traverse quasiment toutes mes conversations de coaching, car chaque CTO avec qui je travaille gère une version différente du même défi : comment piloter une organisation à travers une transformation de cette ampleur, à son stade spécifique, avec sa propre équipe, et en sortir une entreprise plus forte ?

La zone turbulente de la courbe de croissance

Ma propre organisation est petite et volontairement allégée, une équipe fondatrice de quatre personnes bâtissant entièrement autour de l’IA, ce qui nous permet de rester au plus près des réalités du développement produit en phase de démarrage. J’agis aussi en tant que CTO fractionné auprès d’une startup fintech pré-accréditation, sous la pression particulière de lancer un produit réglementé en collaborant avec une équipe externe.

Mais l’essentiel, et là où s'obtient une vraie profondeur d’exposition organisationnelle, ce sont les CTOs que j’accompagne. Cela va des équipes fondatrices et startups autofinancées aux scale-ups à forte croissance soutenues par VC et PE, en passant par des entreprises de taille moyenne confrontées à de véritables complexités organisationnelles, jusqu’aux grands groupes opérant à grande échelle.

La zone turbulente de la courbe de croissance, c’est là où je passe l’essentiel de mon temps, et c’est là que les défis de leadership sont les plus aigus.

Comment l’IA permet aux ingénieurs de prendre du recul

Selon moi, le changement le plus important n’est ni l’outil ni le processus ; c’est une attente. En tant que leader, lorsque vous donnez à l’équipe l’autorisation — et plus encore, l’obligation — de réévaluer tout le cycle de livraison depuis la base, l’étendue de cette remise en question a un sens. Il ne s’agit pas seulement de comment le code est écrit ou déployé, mais de tout ce que le processus de livraison implique : le support client, la valeur pour l’utilisateur, et la finalité business cachée derrière chaque tâche.

Quand le coût de la rédaction et de la maintenance du code était élevé, garder les ingénieurs focalisés étroitement sur le volet technique avait sa raison d’être. Mais ce coût s’est effondré. Le facteur limitant n’est plus la vitesse de développement, c’est la clarté de la compréhension collective de ce qui mérite réellement d’être construit, et pourquoi.

Des ingénieurs qui comprennent le produit, l’utilisateur et les objectifs business derrière un changement peuvent prendre des décisions et agir de façons auparavant inaccessibles. Ce qui a progressé n’est pas une métrique. C’est la qualité des questions que l’équipe s’est mise à poser avant même d’écrire une ligne de code.

Réflexions d'Adam

Le facteur limitant n’est plus la rapidité d’exécution, mais la clarté avec laquelle chaque personne impliquée comprend ce qu’il vaut réellement la peine de construire – et pourquoi.

Comment l’IA permet de raccourcir les cycles de tri et de correction

Un exemple a impliqué une remise à plat de l’interaction entre support client et équipe technique autour des bugs confirmés. Autrefois, les cycles de tri et de correction se comptaient en jours ou semaines : les équipes support géraient les clients frustrés pendant que les ingénieurs pâtissaient de l’interruption des incidents en production. Une fois le cycle de livraison réexaminé à la lumière du développement assisté par IA, les délais de correction se sont réduits drastiquement, et la majorité du processus s’est automatisée.

Cela a alourdi la charge du support en amont, pour bien capturer et catégoriser les soucis, mais le bénéfice était une résolution en quelques heures au lieu de plusieurs jours. Les ingénieurs pouvaient rester concentrés. Les clients obtenaient des réponses plus rapidement. L’interface entre deux fonctions jusque-là considérée comme lente s’est révélée entièrement renégociable.

Pourquoi les organisations ne devraient pas appliquer l’IA à tout

En ce qui concerne la distinction entre tâches humaines et tâches confiées à l’IA, cela diffère pour chaque organisation. Le bon point de départ n’est pas une liste d’activités, mais une compréhension claire de l’endroit où se situe votre valeur et où vos risques sont concentrés.

Les parties du processus qui constituent le cœur de l’activité — la logique, la différenciation, les zones où l’échec est visible ou coûteux — justifient une intervention et une supervision humaines. Tout le reste se situe sur un spectre.

Une entreprise de cybersécurité accordera une attention humaine significative aux propriétés de sécurité de son code, car cela constitue son activité principale. Une entreprise spécialisée dans l’automatisation des flux de travail concentrera la même attention sur la logique de décision d’un flux critique, tout en considérant que la sécurité peut être gérée de manière adéquate par l’IA.

Ce qui est problématique, c’est l’application d’une politique uniforme dans un sens ou dans l’autre. La question n’est pas « L’IA peut-elle faire cela ? » mais « Quel est le coût si cela tourne mal ? »

Et voici encore une chose : Une part surprenante de la complexité que l’on souhaite automatiser correspond en réalité à une dette de processus non résolue. Commencez par résoudre cela. Adopter l’IA sera alors plus simple et moins coûteux par la suite.

Adam partage ses conseils

Le bon point de départ n’est pas une liste d’activités mais une compréhension claire de l’endroit où se situe votre valeur et où vos risques sont concentrés.

Pourquoi les CTO doivent commencer par automatiser la livraison, pas le code

Il est réellement difficile de comparer les résultats de l’IA entre organisations, car la plupart des dirigeants, dans la technologie comme dans le reste de l’entreprise, peinent encore à mesurer clairement l’impact et le retour sur investissement de leurs initiatives liées à l’IA. Sans cela, il est difficile de savoir à quoi ressemble la réussite, et plus encore de justifier d’aller plus loin.

Cependant, la gamme des résultats de l’IA est très large. D’un côté du spectre, j’ai travaillé avec des organisations qui ont réussi à éliminer efficacement leur arriéré et œuvrent désormais en fonction de la valeur client et de l’intention business — un changement fondamental dans la relation entre l’ingénierie et le reste de l’entreprise.

J’ai remarqué un schéma commun chez celles qui y sont parvenues : aucune d’elles n’a commencé par le début du cycle de développement logiciel. Elles n’ont pas débuté par la génération de code. Elles ont démarré par la droite : pipelines CI/CD, fiabilité des déploiements, revue de code automatisée. Renforcer et fiabiliser d’abord la phase de livraison a permis de créer les conditions nécessaires pour le reste. À partir de là, l’accent s’est porté sur les tests, les contraintes, et les vérifications avant même la génération, et sur la structuration plutôt que la rapidité.

Les équipes ayant progressé le plus loin étaient aussi celles qui fonctionnaient le plus en autonomie — non parce qu’elles avaient supprimé le jugement humain, mais parce qu’elles en avaient suffisamment codifié dans leurs processus pour pouvoir accomplir nettement plus, en toute confiance. Le backlog n’a pas disparu parce qu’elles produisaient du code plus vite, il a disparu car le lien entre l’intention et la livraison est devenu limpide.

À l’autre extrémité, j’ai aussi constaté de réels départs en interne liés au fossé croissant entre ceux qui avancent vite avec l’IA et les autres. Quand l’adoption débute, il existe presque toujours un petit groupe qui accélère tandis qu’une majorité reste en retrait, et l’instinct naturel est de laisser filer les premiers. Mais cela génère, rapidement et en silence, des tensions, de la défiance et de la méfiance entre équipes qui sapent les progrès accomplis avant même qu’ils aient pu s’accumuler. Le conseil que je donne désormais au début de chaque mission reste le même : ne laissez personne de côté. Le rythme d’adoption doit être dicté par la capacité de toute l’organisation à avancer ensemble, et non par celle de quelques ingénieurs particulièrement motivés.

Une organisation « à deux vitesses » peut donner une impression de progrès à l’avant. Mais à l’arrière, on a surtout l’impression d’être abandonné — et ce ressenti a des conséquences.

Pourquoi la base de connaissances d'une organisation doit être repensée pour l'IA

Le principal écart que j'ai observé dans les capacités de l'IA réside dans la prise de décision en situation d'incertitude.

L'IA est fondamentalement un moteur de prédiction, et la prédiction n'est pas un jugement. Elle n'est pas engagée, n'a pas le sens des conséquences, ni la responsabilité du résultat. Lui déléguer la prise de décision ne sera donc jamais aussi fiable que sa capacité à prédire, laquelle est limitée dans les situations réellement incertaines ou inédites. Les organisations les plus déçues par l'IA sont généralement celles qui ont compté sur elle précisément dans ces moments-là.

L'autre domaine où l'impact de l'IA est inférieur aux attentes, de façon plus discrète mais tout aussi significative, concerne la mauvaise compréhension des implications des fenêtres de contexte. Fournissez à une IA un contexte incomplet ou mal structuré, et elle vous donnera tout de même une réponse assurée. Savoir distinguer une sortie bien informée d'une réponse simplement vraisemblable requiert un jugement humain que peu d'équipes ont encore développé.

C'est pourquoi la base de connaissances d'une organisation est essentielle. J'entends par là tout le contexte qui vit actuellement dans la tête des collaborateurs : la façon dont les choses ont toujours été faites, les approches par défaut, les règles non écrites qui régissent le fonctionnement réel de l'organisation. L'IA ne peut pas exploiter des connaissances institutionnelles qui n'ont jamais été formalisées, et la plupart des organisations en détiennent une quantité colossale.

La bonne nouvelle, c'est qu'il n'est pas nécessaire de parfaitement structurer ces connaissances pour les exploiter. Grâce à l'IA multimodale, une vidéo explicative, un schéma approximatif ou un document non corrigé constituent déjà des apports précieux. L'essentiel est d'externaliser d'abord, de structurer ensuite.

Ce que je constate systématiquement, c'est que le simple fait de sortir ce contexte de la tête des gens et de le consigner sous n'importe quelle forme est en soi bénéfique, même avant toute utilisation de l'IA. Cela fait ressortir des divergences, met en lumière de mauvaises hypothèses et révèle des processus dysfonctionnels, jusque-là inaperçus car trop intériorisés.

Sur cette base, tout ce que l'IA pourra faire ensuite s'en trouve démultiplié. C'est l'un des leviers les plus puissants sur lesquels un CTO peut investir du temps aujourd'hui — et pourtant l'un des plus souvent négligés, alors que les commerciaux de Business Process Automation nous le répètent depuis des années !

Comment empêcher les développeurs sceptiques de ralentir une organisation

Un problème courant que j'observe n'est pas vraiment une faiblesse de l'IA, mais un échec d'adoption, qui suit généralement un schéma bien reconnaissable.

Un développeur sceptique — et ils sont étonnamment nombreux — tente l'expérience avec un contexte minimal, obtient un mauvais résultat et présente ce dernier comme la preuve que l'IA ne fonctionne pas. La conclusion est affirmée avec assurance. La méthodologie est rarement remise en question. Ce qui fait de cette situation plus qu'une simple frustration individuelle, c'est l'effet en cascade.

L'intégration de l'IA à une équipe ou dans le cycle de développement est un travail collectif, et quelques ingénieurs motivés à prouver que cela ne marche pas peuvent ralentir toute l'organisation, pas seulement leur propre production.

La leçon que j'en tire ne concerne pas les limites de l'IA, mais souligne que l'adoption constitue autant un défi de management que technologique. La qualité de ce que produit l'IA ne peut être dissociée de la qualité du contexte et des intentions qu'on lui donne, et instaurer cette compréhension au sein d'une équipe requiert le même effort délibéré que tout autre changement majeur dans les modes de travail. C'est ainsi que nous passons d'une vision erronée d'une "magie imparfaite" à l'utilisation réelle d'une "technologie avancée".

Partage d'Adam

Un développeur sceptique fait une tentative à moitié engagée avec un contexte minimal, obtient un mauvais résultat et présente ce résultat comme preuve que l’IA n’est pas capable de faire le travail. La conclusion est énoncée avec assurance. La méthodologie est rarement examinée.

Pourquoi les petites équipes sont un avantage avec l'IA

L'hypothèse selon laquelle une équipe d’ingénierie performante et productive avait besoin d'un certain effectif pour porter suffisamment de contexte et avancer à un rythme significatif n'a pas survécu à la réalité du développement assisté par l'IA.

Le facteur limitant dans toute équipe a toujours été d’ordre cognitif : combien de contexte chaque personne peut retenir, à quel point elle peut le communiquer clairement aux gens autour d’elle, et combien d'énergie cette communication consomme. Ce qui a changé, c’est que l’unité de travail n’est plus seulement une personne. Chaque membre de l’équipe utilise plusieurs agents, et ces agents portent et appliquent le contexte d’une façon qui change totalement l’équation. La règle des deux pizzas d’Amazon était une bonne heuristique pour un monde sans IA.

Voici un exemple.

Une organisation avec laquelle je travaille a toujours voulu une interface d'administration interne pour sa plateforme, mais n'a jamais pu justifier l'investissement. Elle l'avait estimée auparavant comme un effort impliquant toute l’équipe sur plusieurs mois. Finalement, ils ont mobilisé deux personnes : toutes deux avec une connaissance approfondie de l’entreprise et de la plateforme existante, une grande autonomie et un ensemble clair de contraintes. Six semaines plus tard, ils avaient une première version fonctionnelle.

La connaissance métier de ces deux personnes s’est révélée aussi importante que les outils d’IA. Moins de questions, moins d’efforts, des décisions plus rapides. Mais le résultat le plus précieux n’était pas l’outil lui-même. C’est ce que l’organisation a appris sur cette manière de travailler.

Les équipes qui sont les plus efficaces à l’heure actuelle, d’après ce que je constate, se composent de deux ou trois personnes, chacune pilotant plusieurs agents, et cela n’est pas une contrainte. Pour le bon type de mission, c’est un réel avantage.

Pourquoi la communication fréquente est cruciale avec les workflows alimentés par l’IA

La collaboration peut devenir difficile avec l’IA.

Une communication beaucoup plus fréquente est nécessaire car tout avance plus vite. C’est l’une des raisons pour lesquelles les équipes restreintes fonctionnent mieux actuellement.

Il semble simplement trop épuisant de maintenir l’état et la cohérence au sein d’une grande équipe avec plusieurs processus de codage parallèles pilotés par des agents pour chaque personne. Certaines des équipes avec lesquelles je travaille sont passées à deux réunions debout par jour pour maintenir la cohérence.

Pourquoi les CTO doivent être vigilants face à l’IA de l’ombre

L’IA de l’ombre correspond au problème déjà connu du système informatique non contrôlé (shadow IT) avec un nouveau budget et un nouveau nom.

L’utilisation non contrôlée et sans restrictions des outils d’IA dans l’entreprise peut facilement augmenter les risques de perte de données et de propriété intellectuelle — « exfiltration » comme le dit le CISO — souvent totalement involontairement de la part des utilisateurs.

La plupart des organisations sortent très rapidement de la phase 1 du CMM (la phase d’expérimentation « Far West ») afin de mettre en place des politiques et des contraintes techniques pour réduire les risques.

Pourquoi les CTO doivent se concentrer sur leur propre développement

Réflexions d’Adam

Les dirigeants qui sortiront le plus forts de cette période ne seront pas forcément ceux dotés des meilleurs outils ou des plus grandes équipes. Ce seront ceux qui développent le discernement, l’influence et la clarté d’esprit nécessaires pour bien diriger lorsqu’il n’existe aucune carte précise.

Le secteur est actuellement traversé par une forte anxiété concernant ce que l’IA signifie pour les équipes d'ingénierie, pour les effectifs, pour le rôle lui-même.

Que cette anxiété soit justifiée ou non est presque secondaire. Ce qui importe, c’est que nous traversons une période de changement important et rapide, et bien la négocier exige des responsables qui investissent activement dans leur propre développement, et pas seulement dans la gestion du changement autour d’eux.

Ce qui continue de me surprendre, vu tout ce qui se passe, c’est le nombre de CTO et de responsables technologiques seniors qui évoluent sans aucun investissement structuré dans leur propre progression. Pas de coach, pas de parcours de développement, pas de partenaire de réflexion. Je l’ai déjà fait moi-même, et les erreurs commises, le temps perdu ne sont pas une fatalité.

Les dirigeants qui sortiront le plus forts de cette période ne seront pas forcément ceux dotés des meilleurs outils ou des plus grandes équipes. Ce sont eux qui développent le discernement, l’influence et la clarté d’esprit nécessaires pour bien diriger lorsque personne n’a une carte précise.

Suivre l’actualité

Vous pouvez suivre le travail d'Adam Horner sur LinkedIn. Pour un accompagnement individuel, des formations en groupe et le podcast, rendez-vous sur The CTO Playbook. Et pour un cours gratuit par e-mail de 5 jours destiné aux CTOs en début de carrière, rendez-vous sur Early CTO Map.

D'autres interviews d'experts seront bientôt disponibles sur The CTO Club !