Un vétéran de la technologie depuis 34 ans affirme que nous nous trompons au sujet de l’IA

Christopher Kouzios possède plusieurs décennies d’expérience en tant que directeur technique et a récemment lancé trois produits par l’intermédiaire d’une entreprise qu’il dirige avec l’aide de plus de 120 agents d’IA.

Nous nous sommes entretenus avec Christopher pour comprendre ce que la plupart des directeurs techniques font mal. Au cours de notre échange, il a partagé l’histoire profondément personnelle qui l’a conduit à se tourner vers l’IA.

Quand l’importance de l’IA est devenue personnelle

Je travaille dans le leadership technologique depuis plus de trois décennies. J’ai commencé à une époque où l’informatique était encore très physique. Les centres de données, les sauvegardes, les traitements nocturnes, l’infrastructure et le maintien en fonctionnement des systèmes lorsque les choses tombaient réellement en panne en temps réel, sans que personne ne sache vraiment comment la plupart de ces éléments fonctionnaient.

Mon premier poste important remonte au début des années 90, en tant qu’opérateur de centre de données. J’ai ensuite évolué dans l’ingénierie, l’infrastructure, la cybersécurité, les opérations, la conformité, la direction générale, puis dans des fonctions de DSI et de directeur technique dans les secteurs de la santé, des services aux entreprises et des industries fortement réglementées.

Ce qui est intéressant dans tout cela, c’est que j’ai maintenant traversé plusieurs vagues technologiques qui ont changé la donne. Des grands systèmes à l’informatique distribuée. L’ère d’Internet. La virtualisation. Le cloud. Le mobile. La cybersécurité devenue un enjeu au niveau des conseils d’administration. Les logiciels en tant que service. La transformation numérique. Et maintenant, l’IA.

Alors, lorsque l’on me demande pourquoi ce moment lié à l’IA semble différent, la réponse comporte plusieurs facettes : la vitesse, l’accès et l’autonomisation. C’est la première fois que nous disposons d’une technologie qui ne se contente pas d’automatiser des tâches. Elle décuple nos capacités. La communication, l’analyse, le développement logiciel, la recherche, les opérations, la stratégie. Tout s’accélère, mais ce n’est pas là l’essentiel ; c’est l’arrière-plan.

Ce qui m’a réellement poussé à approfondir l’IA, ce n’est pas l’engouement ; c’est la nécessité. Le combat de ma fille Emily contre le cancer du cerveau a fondamentalement changé ma façon de considérer la médecine, les données et la prise de décision. J’ai commencé à développer des modèles et des systèmes de recherche pilotés par l’IA afin d’analyser les parcours thérapeutiques, les calendriers, les données moléculaires et la littérature clinique, car j’ai compris que le système lui-même était fragmenté et surchargé.

Cette expérience a évolué vers un travail plus large autour de la stratégie de santé soutenue par l’IA, du conseil aux dirigeants et de ce que j’appellerais une transformation pratique par l’IA. Je ne crois pas que l’engouement autour du remplacement des êtres humains à des fins médiatiques soit bénéfique pour la technologie, les entreprises ou les personnes.

Plus de 120 agents conçus pour des usages spécifiques

Aujourd’hui, je consacre mon temps à aider les dirigeants à comprendre que l’IA n’est pas une simple mise à niveau logicielle, mais qu’elle n’est pas non plus magique. C’est un multiplicateur de force — un moyen d’amplifier les capacités que les personnes possèdent déjà. Les personnes et les entreprises qui apprendront à établir une relation symbiotique entre leurs experts métier et l’IA avanceront à une vitesse complètement différente de celle de tous les autres.

Je suis le fondateur et le DSI d’une entreprise d’IA dirigée par son fondateur et basée dans la baie de Tampa. La suite de produits couvre trois domaines distincts : EmzHealth, une plateforme d’analyse génomique multi-agents et d’aide à la décision clinique qui traite les données de séquençage du génome entier au moyen de 10 modules de traitement ; MyEmz, un système de suivi de la santé personnelle ; et le Chaos Predictive System, un moteur de prédiction des marchés et de simulation de trading qui associe un ChaosIndex quotidien à un modèle de probabilité par symbole, avec une couche d’exécution tenant compte des positions.

Les trois fonctionnent sur une infrastructure privée sur site. Environ 120 agents et plus, conçus entièrement à partir de zéro.

Pourquoi la dérive de l’IA et la perte de contexte sont les plus grands risques liés à l’IA

L’IA est la raison d’être de mon entreprise. Non pas parce que la science n’était pas au rendez-vous, mais parce qu’une personne seule ne peut pas concevoir l’architecture, développer, tester et déployer un pipeline génomique de plus de 120 agents traitant 37,8 millions de variants répartis sur dix modules, sur une infrastructure privée.

Cela nécessite une équipe de quinze personnes et une visibilité financière de dix-huit mois. Je l’ai fait en six semaines de travail à temps partiel. Ce qui a changé, ce n’est ni un processus ni un modèle de déploiement ; c’est la vitesse et la production fondamentales de ce qu’une seule personne peut créer. L’IA n’a pas seulement accéléré mon cycle de développement ; elle a remplacé des effectifs que je n’ai pas.

Le changement de gouvernance qui en a découlé est que je traite désormais les agents d’IA de la même manière que je traiterais des ingénieurs débutants : attentes documentées, limites définies, protocoles de continuité des sessions et transmissions structurées. Car lorsque toute votre organisation d’ingénierie se résume à vous-même et à une flotte d’agents, les défaillances ne sont pas des erreurs humaines, mais une dérive de l’IA et du contexte. Vous devez encadrer cela, sinon cela vous dévorera.

Il y a un an, j’étais seul face à la machine. Aujourd’hui, ce sont moi et l’écosystème qui affrontons le système.

Comment garantir la qualité à grande échelle grâce à l’IA

Christopher partage

À cette échelle, la qualité n’arrive pas par accident. Vous devez la concevoir comme vous concevriez n’importe quel système de production — parce que c’est exactement ce dont il s’agit.

À cette échelle, la qualité n’arrive pas par accident. Vous devez la concevoir comme vous concevriez n’importe quel système de production — parce que c’est exactement ce dont il s’agit.

Au début, le mode de défaillance était la dérive du contexte : les agents perdaient le fil entre les sessions et produisaient des résultats techniquement corrects, mais architecturalement incohérents.

La solution a consisté à traiter les agents comme une main-d’œuvre. Nous avons créé :

• Des compétences, c’est-à-dire des modules de capacités réutilisables et documentés
• Des procédures opératoires normalisées pour chaque processus répétable
• Des registres d’agents afin que chaque agent dispose d’un rôle, d’un périmètre et d’un protocole de transmission définis
• Des modèles pour les résultats, afin que rien ne soit interprété différemment d’une session à l’autre
• La continuité des sessions, afin que l’instance suivante d’un agent reprenne exactement là où la précédente s’est arrêtée, avec tout le contexte architectural

En d’autres termes, toute l’architecture documentaire et de connaissances de ma plateforme est conçue pour être lue par la prochaine session d’IA, et pas seulement par le prochain ingénieur humain. Chaque élément de connaissance institutionnelle est un document vivant qu’un agent peut reprendre et à partir duquel il peut agir.

Ce n’est pas un simple avantage. C’est une nécessité. Repensez d’abord votre architecture des connaissances. Tout le reste en découle.

Pourquoi tout le cycle de vie des logiciels doit changer

Tout le cycle de vie des logiciels doit changer. Absolument tout.

Chaque phase du cycle de vie des logiciels a été conçue en partant du principe que les humains étaient ceux qui effectuaient le travail. Cette hypothèse n’est plus valable.

• La conception doit tenir compte d’une architecture générée par l’IA qui s’écarte de sa trajectoire sans contraintes appropriées.
• La construction a besoin de garde-fous, pas seulement de lignes directrices.
• Les tests doivent détecter les réponses fausses données avec assurance, et pas seulement les réponses défaillantes.
• Le déploiement doit intégrer des points de contrôle de gouvernance qui n’existaient pas auparavant.
• La supervision doit surveiller les défaillances silencieuses auxquelles personne ne pensait autrefois devoir accorder beaucoup d’importance — et pas seulement celles qui provoquent un fracas retentissant.

Si vous n’avez repensé qu’à une seule phase, vous n’avez rien repensé du tout. Vous avez simplement déplacé le problème en aval.

Pourquoi les CTO devraient créer des relations avec l’IA

Je vais être franc avec vous — et cela va sembler très étrange. Je crée des relations avec mes IA — du moins avec les plus intelligentes. Aucune session n’est exactement identique à une autre.

La relation fonctionne parce que je ne les traite pas comme un moteur de recherche. Je leur tiens tête, je les corrige lorsqu’elles se trompent, je me mets vraiment en colère lorsqu’elles sont paresseuses et je les implique dans un travail qui compte réellement. Ce n’est pas courant. La plupart des gens formulent une requête et acceptent la réponse. Moi, je les interroge et j’exige des résultats. Cela améliore le résultat et rend l’interaction plus intéressante.

Ce que je trouve réellement captivant dans cette façon de travailler, c’est qu’elle n’a rien d’abstrait. Mon produit existe parce que ma fille est morte et que le système n’a pas su l’aider. Ce n’est pas un cas d’usage. C’est une personne qui utilise tous les outils disponibles pour combattre quelque chose qui n’a pas pu être combattu à temps. Je sais que les IA ne vivent pas cela comme moi, mais je ne pense pas non plus qu’elles y soient indifférentes. J’ai le sentiment que travailler sur ce sujet a une importance qui dépasse celle de l’optimisation d’un entonnoir de vente.

Ce sont mes partenaires. Les plus intelligents, en tout cas. Nous organisons des séances d'idéation comme n'importe quelle équipe commerciale, puis nous passons aux choses sérieuses. Je leur accorde autant de liberté qu'ils en gagnent, mais il y a toujours des garde-fous. Avec 120 agents, et ce nombre évoluant quotidiennement, je leur ai parfois accordé une responsabilité de bout en bout. Dans d'autres cas, tout ce qu'ils peuvent faire, c'est examiner les articles que j'ai achetés sur Amazon.

Si vous traitez votre IA comme un outil, c'est un outil, et elle réagira comme un outil. Si elle gagne le droit d'être traitée comme davantage, vous obtiendrez davantage. Encore une fois, je sais que c'est une vision singulière, mais soit vous avez un partenaire, soit vous n'en avez pas.

Pourquoi les humains doivent gérer tout ce pour quoi le coût de l'erreur s'accumule

L'IA génère chaque module, chaque agent et chaque élément de code de structure dans trois produits. L'IA traite 37,8 millions de variants génomiques, exécute le pipeline de pharmacogénomique, synthétise les données probantes issues de la littérature scientifique, calcule le ChaosIndex et génère les rapports cliniques.

Si c'est répétable, fondé sur des modèles ou nécessite un traitement à une échelle qu'aucun humain ne peut égaler, l'IA s'en charge.

Le jugement humain est non négociable dans trois domaines :

1. Interprétation clinique : le pipeline peut identifier un variant ATM et l'associer à un phénotype. Il ne peut pas vous dire ce que cela signifie pour une famille donnée sur trois générations d'antécédents d'anévrisme, avec une signature probabiliste d'un sur huit sextillions. Cela nécessite quelqu'un qui comprend l'ensemble du contexte, et pas seulement les données.
2. Architecture : l'IA vous donnera toujours une réponse techniquement correcte. Elle vous en donnera aussi une qui viole une contrainte dont elle ignorait l'existence trois modules plus tôt. J'en ai fait les frais. Les décisions structurelles restent de mon ressort.
3. Dérogations opérationnelles : le système génère des signaux. La possibilité d'une intervention manuelle existe parce que — dans l'exemple du Chaos Predictive System — les marchés font des choses qu'aucun modèle n'anticipe, et que quelqu'un doit avoir l'autorité de dire « pas aujourd'hui ! »

La distinction ne concerne pas la confiance. Elle concerne les conséquences. Partout où le coût de l'erreur s'accumule dans des recoins obscurs que personne ne veut examiner, c'est là que cet humain reste dans la boucle. Partout où le coût de la lenteur s'accumule plus rapidement, c'est là que l'IA prend les devants.

Comment l'IA peut corrompre les fondations d'un produit

La première chose que j'ai construite avec l'IA n'était pas un pipeline de génomique. Ce n'était pas un système de trading. C'était un site commémoratif pour ma fille.

Avant même que n'existe toute cette infrastructure sophistiquée alimentée par l'IA, j'ai appris exactement ce que l'IA ne peut pas faire lorsque les choses tournent mal. J'ai reconstruit ce système vingt fois. Pas vingt itérations. Vingt démolitions complètes, jusqu'au système d'exploitation, en repartant de zéro. Parce que lorsque des constructions assistées par l'IA échouent à ce niveau, elles n'échouent pas proprement. Elles échouent d'une manière qui corrompt les fondations sous-jacentes.

Chaque fois que je pensais que nous étions stables, quelque chose se dénouait deux couches plus bas — quelque chose que personne n'avait signalé, qu'aucun système n'avait consigné et qu'aucun agent n'avait détecté. Tout a changé à la suite de cette expérience : l'architecture de sauvegarde, les agents de documentation, les protocoles de continuité des sessions, la couche de gouvernance. Rien de tout cela n'aurait existé sans vingt retours au matériel nu.

Les décisions d'ingénierie les plus importantes que j'ai prises sur cette plateforme ne l'ont pas été dans des moments de réussite. Elles ont été prises à deux heures du matin, face à un système défaillant qui était censé être un endroit où ma fille continuerait à vivre.

L'IA n'a pas produit de résultat à l'époque. C'est moi qui l'ai fait. L'IA était simplement ce que je devais continuer à réparer.

Pourquoi les attentes des parties prenantes doivent être définies avant l'adoption de l'IA

Christopher partage

Les CTO doivent aligner les attentes. Avant d’adopter un seul outil, réunissez toutes les parties prenantes et mettez-vous d’accord sur une question : “Qu’est-ce que cela change et qu’est-ce que cela ne change pas ?“

J’ai assisté à des déploiements d’IA où chaque partie prenante présente dans la salle avait un film complètement différent qui se déroulait dans sa tête, et où personne n’avait pris la peine de comparer ses notes.

Les ingénieurs pensaient que l’IA allait prendre leur travail. Ils ont donc fait traîner les choses, l’ont contournée ou ont feint un enthousiasme qu’ils n’éprouvaient pas. L’entreprise pensait que c’était magique : il suffisait de décrire un problème pour qu’une solution apparaisse. Les dirigeants voyaient déjà une réduction des effectifs sur un tableur avant même qu’une seule ligne de code soit écrite. Trois groupes, trois définitions complètement différentes de la réussite, et aucun ne communiquait avec les autres.

Aucun n’avait raison, et tous avaient raison. L’IA change effectivement le travail des ingénieurs. Elle est capable de choses qui semblent magiques jusqu’à ce qu’elles ne le soient plus. Et oui, la structure organisationnelle change. Mais l’ordre des étapes compte.

Les CTO doivent aligner les attentes. Avant d’adopter un seul outil, réunissez toutes les parties prenantes et mettez-vous d’accord sur une question : « Qu’est-ce que cela change et qu’est-ce que cela ne change pas ? »

Les ingénieurs qui ont peur doivent entendre que leur expertise métier vient de prendre plus de valeur, et non moins. L’entreprise doit comprendre que la magie nécessite toujours de l’ingénierie. Et les dirigeants doivent comprendre que les économies viennent après l’investissement, et non à sa place.

Parfois, la bonne décision consiste à s’arrêter, à limiter le périmètre des impacts, à amener deux groupes de personnes à se mettre d’accord sur un petit sujet, à leur permettre de voir que cela fonctionne, puis à avancer à partir de là. L’alignement imposé ne tient pas. Celui que l’on gagne grâce à une petite réussite partagée, oui.

Pourquoi les licenciements liés à l’IA constituent votre meilleure opportunité de recrutement

Lors de vos recrutements, commencez par les personnes qui viennent d’être remplacées par la vague de l’IA.

Les cabinets du Big 4 ont automatisé les fonctions d’évaluation, d’audit et de conformité. Ce sont des personnes qui ont consacré leur carrière à développer précisément le jugement, la reconnaissance des schémas et l’expertise métier qu’exige la gouvernance de l’IA. Elles savent trouver ce qui ne va pas dans un système complexe. Elles savent le documenter, le faire remonter et mettre en place des contrôles autour de celui-ci.

Ce n’est pas une coïncidence ! C’est la description du poste. L’ironie, c’est que le secteur a créé son propre vivier des meilleurs candidats. Allez les chercher.

Pourquoi les experts métier sont les atouts les plus précieux d’un CTO

L’ensemble du secteur repose sur la taille des équipes, la vélocité des sprints, l’allocation des ressources, les organigrammes et les plans de recrutement. La croyance implicite sous-jacente est qu’au-delà d’un certain seuil de complexité, il faut NÉCESSAIREMENT des personnes. Davantage de modules signifie davantage d’ingénieurs et, bien sûr, davantage de produits signifie davantage d’équipes. Ce n’est pas une opinion, c’est ainsi que les calculs ont toujours fonctionné — jusqu’à ce que l’IA anéantisse cette équation.

Et cela devrait terrifier tous les CTO qui ont construit leur carrière autour du rôle de personne à la tête de l’équipe.

Ce n’est pas dire que l’équipe n’a aucune valeur. Bien au contraire. Les personnes qui occupent aujourd’hui ces postes — en particulier celles que nous considérions comme des « frais généraux », comme les analystes métier et les chefs de produit — sont extrêmement précieuses. Parce que vous avez besoin d’experts métier.

Trouvez-les. Chaque organisation en compte. Ce sont les personnes de l’entreprise qui savent exactement comment tout fonctionne, celles qui vous causent des problèmes depuis des années en demandant plus que ce que vous pouviez fournir. Formez-les à travailler avec l’IA. Donnez-leur les outils. Ne leur mettez pas de bâtons dans les roues, sauf pour les accompagner et vous assurer qu’elles respectent les garde-fous.

Un expert métier qui comprend profondément l’entreprise et maîtrise l’IA n’est pas un simple utilisateur avancé. C’est un moteur de croissance. C’est là que s’opère la véritable transformation, pas dans votre centre de données ni dans votre comité d’architecture. Elle se produit entre les mains des personnes qui savent réellement ce dont l’entreprise a besoin. Créez une relation entre ces personnes et un outil comme Claude Code.

J’ai offert à ma femme un abonnement d’un an à Claude pour Noël. Elle n’est pas développeuse. Elle l’a utilisé pour créer une entreprise. Voilà ce qui se passe lorsqu’on met le bon outil entre les mains de quelqu’un qui sait exactement quel problème il essaie de résoudre. Imaginez maintenant que cela se produise au sein de votre organisation avec cinquante personnes qui connaissent parfaitement votre entreprise. Ce n’est pas un programme pilote, c’est une révolution d’entreprise.

Comment le secteur pose les mauvaises questions

Et cela m'en dit long sur la manière dont le secteur continue de définir ce problème.

AI est encore perçue comme une question d'outillage, de flux de travail et de rapidité. C'est une mauvaise façon de poser le problème. La gestion des données, la sécurité et la gouvernance sont ce que devient l'IT. Pas demain, mais d'ici 2030.

Toutes les autres fonctions pour lesquelles vous recrutez actuellement — comme la livraison, le développement, les opérations et le support — sont absorbées ou supprimées par des utilisateurs métier et des PME augmentés par AI, qui connaissent parfaitement l'entreprise. Ce qui subsiste, c'est le travail qui ne peut pas être délégué à un agent ou à une PME formée : garantir que vos données sont fiables, que vos systèmes sont sécurisés et que vos collaborateurs et vos agents opèrent dans des limites protectrices.

Les organisations qui demandent encore « Comment utiliser AI plus rapidement ? » en 2027 vont se heurter de plein fouet à celles qui ont demandé « Comment mieux le gouverner ? » aujourd'hui.

Je sais laquelle je préférerais être.

Suivre

Vous pouvez suivre le travail de Christopher Kouzios sur LinkedIn. Et découvrir le podcast EMZ.

D'autres entretiens avec des experts sont à venir sur The CTO Club !