Le directeur technique affirme que l’IA a besoin d’un nouveau modèle de gouvernance

Tyrone Grandison a occupé de nombreux postes de direction au cours de ses 35 années de carrière dans la technologie et il est actuellement CTO de Cornerstone Assurance Corporation. Il est également l’auteur de La révolution de l’IA et la culture qui perdure.

Nous nous sommes entretenus avec Tyrone pour comprendre comment l’IA transforme la gouvernance au sein des organisations technologiques. Voici ce qu’il nous a expliqué.

35 ans dans la technologie

Je dirige une organisation technologique légère qui accompagne une entreprise en pleine croissance dans les secteurs de l’assurance et des services financiers, appelée Cornerstone Assurance Corporation. Ce qui rend ce rôle particulièrement intéressant, c’est que nous construisons une pile technologique moderne tout en évoluant dans un secteur soumis à d’importantes exigences réglementaires, qui traite des données financières sensibles, repose sur des intégrations complexes avec les assureurs et tolère très peu les erreurs.

J’ai commencé ma carrière comme informaticien, bien avant que l’IA ne devienne le sujet de toutes les conversations dans les conseils d’administration et de toutes les conférences. Au fil des années, mon travail m’a conduit à passer de la conception de technologies à la direction d’organisations confrontées aux effets de ces technologies. J’ai occupé les fonctions de directeur de l’intelligence artificielle, de directeur de la technologie, de directeur des systèmes d’information et de directeur adjoint des données. J’ai travaillé dans les secteurs public et universitaire, ainsi que dans des startups, des cabinets de conseil, des organisations à but non lucratif et de grandes entreprises.

Après 35 ans dans la technologie, j’ai eu le privilège de voir plusieurs choses être présentées comme « la technologie qui va tout changer ». Et certaines l’ont effectivement fait.

Chaque changement majeur oblige les dirigeants à prendre des décisions avant de disposer d’informations parfaites. Il remet en question les modèles économiques, les modèles opérationnels, la culture, les talents, la gouvernance et parfois même notre compréhension de ce que nos propres emplois sont censés être. L’IA fait tout cela à la fois.

Mais ce qui rend ce moment particulièrement fascinant à mes yeux, c’est que nous sommes allés au-delà d’une IA qui nous aide simplement à analyser des informations. Nous disposons désormais de systèmes capables de générer, de raisonner, de planifier, de créer, d’écrire du code, d’utiliser des outils et, de plus en plus, d’agir. Cela change fondamentalement la conversation sur le leadership.

La question était autrefois : « Que peut faire l’IA ? »

Je pense que cette question devient rapidement la moins intéressante. C’est même la mauvaise question.

Les questions bien plus importantes sont les suivantes : Que devrions-nous lui permettre de faire ? Dans quels domaines le jugement humain reste-t-il essentiel ? Comment repenser les organisations lorsque la compréhension elle-même devient abondante ? Et comment tirer parti du potentiel extraordinaire de cette technologie sans créer des risques que nous ne comprenons pas ou des systèmes que nous ne pouvons pas gouverner ?

C’est là que se situe mon travail aujourd’hui. Je travaille avec des dirigeants et des organisations pour les aider à distinguer le signal de la quantité considérable de bruit qui entoure l’IA, à comprendre ce qui change réellement et à transformer cette compréhension en stratégie, en gouvernance, en produits et en résultats commerciaux mesurables.

Comment l’IA transforme les cycles de développement logiciel

L’un des changements les plus importants que j’ai apportés chez Cornerstone Assurance Corporation a été de repenser notre cycle de développement logiciel en partant du principe que l’IA écrira une part significative de notre code.

Avant ce changement, nous suivions un flux de travail d’ingénierie assez traditionnel. Un développeur prenait en charge une exigence, concevait la solution, écrivait le code, créait les tests, soumettait une demande d’intégration et un autre ingénieur l’examinait. Nous utilisions bien sûr l’automatisation, mais les humains effectuaient encore la majeure partie du travail cognitif, de l’exigence au déploiement.

L’IA a complètement changé l’économie de ce modèle.

Nous avons donc mis en place une chaîne de développement assisté par l’IA utilisant GitHub Copilot pour la génération et la refactorisation du code, ChatGPT et Claude pour l’exploration architecturale pilotée par l’IA, la décomposition des exigences, le débogage et la génération de cas de test, tandis que nos outils habituels d’intégration et de déploiement continus et de sécurité fournissaient les contrôles déterministes autour du travail généré par l’IA.

Pourquoi le code généré par l’IA nécessite un nouveau modèle de gouvernance

Mais le changement important n’était pas : « Hé, tout le monde, vous avez maintenant Copilot. » Nous avons modifié le modèle de gouvernance.

Points de validation

Nous traitons désormais le code généré par l’IA presque comme du code soumis par un ingénieur junior très rapide qui ne dort jamais, a lu une quantité absurde de documentation et dit parfois quelque chose de complètement faux avec une assurance extraordinaire.

Cela signifie que l’IA peut générer du code, des tests unitaires, des contrats d’API, de la documentation, des requêtes de base de données, des définitions d’infrastructure et des corrections proposées, mais qu’elle ne peut pas approuver son propre travail ni disposer d’un accès incontrôlé à la production.

Nous avons instauré des points de validation humains explicites pour les modifications sensibles sur le plan de la sécurité, l’authentification et l’autorisation, la gestion des données clients et financières, les intégrations externes et l’infrastructure de production.

Tests automatisés

Nous avons également étendu les tests automatisés et la revue de code, car le goulot d’étranglement s’est déplacé. Lorsque l’IA augmente considérablement la vitesse à laquelle vous pouvez produire du code, votre problème n’est plus la génération de code. Votre problème devient de prouver que le code mérite d’être exécuté.

La création de tests en est un exemple simple. Auparavant, un ingénieur pouvait implémenter une fonctionnalité, puis écrire les tests unitaires évidents. Désormais, nous pouvons également demander à l’IA de générer des cas de test contradictoires. Que se passe-t-il avec une entrée malformée ? Que se passe-t-il lorsqu’une API renvoie une réponse inattendue ? Que se passe-t-il à la frontière des autorisations ? Que se passe-t-il lorsqu’un enregistrement client contient des données incomplètes ?

Cela donne à l’ingénieur humain une autre mission. Au lieu de consacrer tout son temps à produire des artefacts, il passe davantage de temps à remettre en question les hypothèses et à valider le comportement du code.

Gouvernance de l’IA

Nous avons également modifié la façon dont nous gouvernons l’IA elle-même. Nous enregistrons l’activité assistée par l’IA lorsque cela est approprié, gardons les informations sensibles sur les clients à l’écart des outils d’IA grand public, contrôlons les modèles et services qui peuvent accéder aux données de l’entreprise et séparons l’expérimentation de l’accès à la production. Dans l’assurance et les services financiers, « le modèle pensait que c’était une bonne idée » ne constituera jamais une stratégie de gouvernance.

Comment l’IA déplace le goulot d’étranglement de l’ingénierie

Le principal résultat que j’ai constaté en intégrant l’IA à nos flux de travail d’ingénierie est la rapidité, mais j’ajoute toujours un astérisque à cette réponse, car la rapidité dans la mauvaise direction n’est pas de la productivité.

L’IA a considérablement réduit la durée de notre cycle de développement. Nous constatons que des tâches qui prenaient auparavant plusieurs jours à un développeur passent désormais des exigences à une implémentation testable en quelques heures. Pour le prototypage en particulier, j’estime que nous avons réduit la durée du cycle d’environ 50 à 70 %.

Et la documentation a probablement produit le gain d’efficacité le moins spectaculaire, mais le plus immédiat. La documentation des API, les notes de version, la documentation des tests, les explications du code et les premières ébauches de spécifications techniques n’ont plus besoin de commencer par un curseur clignotant. L’IA produit les 70 ou 80 % initiaux, et mon équipe consacre son temps à corriger et à améliorer plutôt qu’à tout créer à partir de zéro.

Mais il y a un revers, et je pense que les responsables technologiques doivent davantage en parler : l’IA rend incroyablement peu coûteuse la production rapide de mauvais code.

Nous avons découvert que le facteur limitant se déplace en aval. Si je peux générer cinq fois plus de code, mais que les humains doivent toujours le comprendre, le relire, le tester, le sécuriser, le déployer, le surveiller et le maintenir, je n’ai pas nécessairement augmenté le débit du système. J’ai peut-être simplement créé un embouteillage au niveau de la revue de code.

C’est probablement la leçon qui m’a été la plus utile. Je n’optimise plus principalement mon organisation d’ingénierie en fonction de la rapidité avec laquelle nous pouvons écrire des logiciels. L’IA banalise rapidement cette partie. J’optimise la rapidité avec laquelle nous pouvons prouver qu’un logiciel mérite d’être exécuté en production. Il s’agit d’une organisation d’ingénierie très différente.

Là où l’IA peut s’exprimer, et là où elle peut décider

Je suis devenu assez méthodique lorsqu’il s’agit de séparer deux choses : les domaines où l’IA peut s’exprimer et ceux où elle peut décider. Dans notre organisation, l’IA intervient désormais à presque toutes les étapes du cycle de vie de nos technologies. Elle ne prend pas part à chaque décision.

Quelques exemples :

• Architecture : Nous utilisons ChatGPT et Claude comme partenaires de réflexion architecturale. Si nous concevons un nouveau service, je peux fournir au modèle nos exigences, nos contraintes, nos interfaces existantes, nos limites de sécurité, le volume de transactions attendu et les scénarios de défaillance. Je lui demande de proposer plusieurs architectures, d’identifier les compromis, de remettre en question nos hypothèses et même d’argumenter contre sa propre recommandation. En revanche, je ne lui demanderai pas : « Quelle architecture devrions-nous utiliser ? », pour ensuite construire ce qui en ressort. La décision finale concernant l’architecture reste humaine, car elle implique un contexte qui va bien au-delà de l’optimisation technique. Je dois prendre en compte notre stratégie commerciale, nos obligations réglementaires, notre maturité opérationnelle, notre tolérance au risque, nos coûts, notre dette technique et ce que mon équipe est réellement capable de maintenir à 2 h du matin.
• Code : Nous lui accordons beaucoup plus de latitude dans ce domaine. Nous utilisons GitHub Copilot pour générer du code, effectuer des refactorisations, rédiger de la documentation et créer des tests unitaires. Nous utilisons également ChatGPT et Claude pour résoudre des défauts, explorer des approches d’implémentation et générer des cas de test adverses. L’IA peut rédiger une première implémentation incroyablement rapidement. Un ingénieur reste toutefois responsable de la demande de fusion et approuve ce qui est finalement intégré.
• Tests : C’est probablement le domaine qui s’est le plus orienté vers l’IA. J’aime utiliser l’IA pour demander : « Comment casserais-tu ceci ? » Nous pouvons découvrir des cas qu’un développeur venant de passer deux jours à concevoir la fonctionnalité pourrait inconsciemment négliger. L’IA devient un adversaire très peu coûteux et extrêmement persistant.
• Sécurité : C’est ici que j’inverse délibérément l’équation. L’IA nous aide à identifier les vulnérabilités, à examiner les modèles de code, à modéliser les menaces et à générer des scénarios d’attaque, mais comme je l’ai indiqué, les humains conservent l’autorité en matière d’acceptation de la sécurité, de décisions relatives à l’identité et aux accès, de traitement des données sensibles et de gestion des exceptions. L’injection de requêtes et la divulgation d’informations sensibles restent des risques reconnus dans les applications utilisant des LLM, de sorte que la connexion de l’IA aux systèmes d’entreprise nécessite davantage de contrôles, et non moins.
• Réponse aux incidents : Ce domaine se situe quelque part entre les deux. L’IA peut ingérer des journaux, corréler des événements, résumer des milliers de lignes de données de télémétrie, proposer les causes profondes les plus probables et recommander des mesures correctives. Cela peut considérablement réduire les 30 premières minutes d’un incident. Mais si quelqu’un veut désactiver un service en production, annuler le déploiement d’une fonctionnalité critique, modifier une politique de sécurité ou prendre une mesure qui affecte les clients, c’est un humain qui prend la décision.
• Priorisation du carnet de commandes : J’applique ici la même règle. L’IA peut analyser les problèmes signalés au support, l’effort d’ingénierie, les dépendances, l’utilisation du produit et les objectifs commerciaux, puis dire : « Voici comment je prioriserais ces 40 éléments et voici pourquoi. » C’est extrêmement utile. Mais l’IA ne comprend pas mieux notre stratégie que nous. Les responsables produit et technologie prennent la décision finale en matière de priorisation.

Ma règle est donc assez simple : l’IA bénéficie de davantage d’autonomie lorsque l’action est réversible, observable, testable et peu conséquente. L’autorité humaine augmente à mesure qu’une action devient plus difficile à annuler ou qu’elle entraîne un impact plus important pour les clients, les finances, la sécurité, la réglementation ou la réputation.

Un flux de travail d’ingénierie concret

Voici un exemple de flux de travail « des exigences à la production avec l’IA dans la boucle ». Supposons que nous devions ajouter une nouvelle fonctionnalité à un flux de travail d’agent qui récupère des informations sur les clients et les politiques, applique un ensemble de règles commerciales et recommande l’action suivante appropriée :

1. Tout commence par le besoin. Au lieu qu’un ingénieur reçoive un ticket rédigé de manière vague et se mette immédiatement à coder, nous utilisons ChatGPT ou Claude pour examiner le besoin en profondeur. Nous lui fournissons le récit utilisateur, les critères d’acceptation, les règles métier pertinentes, les contrats d’API et les contraintes techniques. Puis nous lui demandons d’identifier les ambiguïtés, les cas limites manquants, les dépendances, les problèmes de sécurité et les questions auxquelles nous devons répondre avant que quiconque n’écrive du code. Cela paraît simple, mais cette approche permet de détecter très tôt une quantité surprenante de confusions coûteuses.
2. Vient ensuite l’architecture et la décomposition des tâches. Nous utilisons Claude et ChatGPT pour explorer les options d’implémentation et décomposer les besoins en composants. Le modèle peut identifier une modification d’API, une modification du modèle de données, une dépendance d’intégration, des exigences d’autorisation, la télémétrie et les cas de test nécessaires. Nous lui demandons également de contester l’architecture qu’il propose. Un ingénieur humain prend la décision architecturale. L’IA fournit des options. Nous assumons les conséquences.
3. Ensuite, nous passons à l’implémentation. Nous utilisons GitHub Copilot dans l’environnement de développement pour générer le code répétitif, implémenter des fonctions bien définies, refactoriser le code, créer des clients d’API, expliquer les sections méconnues de la base de code et générer de la documentation. L’ingénieur ne saisit plus chaque ligne, mais dirige, vérifie et affine l’implémentation. Cette distinction est importante. Je ne veux pas que les développeurs deviennent des opérateurs de saisie automatique très coûteux. Je veux qu’ils réfléchissent au système.
4. Ensuite, nous donnons à ChatGPT ou Claude le besoin et l’implémentation et nous lui disons en substance : « Très bien. Maintenant, mettez-les à l’épreuve. » L’IA aide à générer des scénarios contradictoires, et Copilot aide à les transformer en tests unitaires et d’intégration automatisés.
5. Ensuite, les mécanismes déterministes prennent le relais. La demande de fusion entre dans notre pipeline CI/CD. Nous exécutons les tests automatisés, l’analyse statique, l’analyse des dépendances et la recherche de vulnérabilités, ainsi que nos contrôles qualité habituels. Un ingénieur humain examine la demande de fusion.
6. Ensuite, nous déployons progressivement. La modification passe par les environnements de développement et de préproduction avant d’atteindre la production. Lorsque cela est pertinent, nous utilisons des indicateurs de fonctionnalité ou des stratégies de déploiement contrôlé afin de limiter l’exposition, d’observer le comportement et de revenir rapidement en arrière.
7. Et le rôle de l’IA ne s’arrête toujours pas là. Une fois la fonctionnalité en production, l’IA devient un assistant d’observabilité. Nous l’utilisons pour résumer les journaux, corréler les schémas d’erreur, analyser les comportements inattendus et aider les ingénieurs à passer beaucoup plus rapidement de « quelque chose ne va pas » à une cause racine plausible.

Comment changer les pratiques d’ingénierie grâce à l’IA

J’aurais aimé comprendre plus tôt que fournir des outils d’IA aux ingénieurs est facile. Modifier les pratiques d’ingénierie est la partie difficile.

Lorsque nous avons commencé à utiliser des outils comme GitHub Copilot, ChatGPT et Claude, j’ai abordé leur déploiement comme le font de nombreux dirigeants du secteur technologique. Fournir à des ingénieurs talentueux des outils puissants, mettre en place quelques garde-fous raisonnables et attendre que la productivité augmente.

Elle a effectivement augmenté, mais pas de manière uniforme et pas toujours de la façon à laquelle je m’attendais.

La première chose que j’ai apprise, c’est que l’accès ne signifie pas l’adoption, et que l’adoption ne signifie pas la maîtrise.

Deux ingénieurs peuvent disposer exactement du même outil d’IA et obtenir des résultats radicalement différents. L’un traite l’IA comme une saisie automatique et économise quelques frappes de touche. L’autre apprend à fournir du contexte, à décomposer les problèmes, à remettre les résultats en question, à générer des tests, à explorer des alternatives et à utiliser le modèle comme partenaire de réflexion technique. L’écart de productivité entre ces deux personnes peut devenir considérable.

J’aurais investi bien plus tôt dans la culture de l’IA et les méthodes de travail. Pas dans une formation de deux heures sur l’ingénierie des prompts, mais dans des exemples pratiques fondés sur notre travail d’ingénierie réel.

Commentaires de Tyrone

J’aurais investi bien plus tôt dans la culture de l’IA et les méthodes de travail. Pas dans une formation de deux heures sur l’ingénierie des prompts, mais dans des exemples pratiques fondés sur notre travail d’ingénierie réel.

Comment l’IA transforme le leadership technologique

Nous consacrons beaucoup de temps à nous demander ce que l’IA va changer pour les développeurs, les architectes, les analystes et les autres fonctions techniques. Je pense que les CTO doivent inverser cette question et se la poser à eux-mêmes.

Pendant la majeure partie de ma carrière, le leadership technologique reposait sur la connaissance de choses que les autres ignoraient. L’expérience permettait de reconnaître des schémas. L’expertise technique conférait de l’autorité. On pouvait entrer dans une salle et fournir une réponse qu’une autre personne aurait peut-être mis plusieurs jours à trouver.

Désormais, je peux mettre un système d’IA incroyablement performant entre les mains de chacun. Cela change le leadership.

Je ne pense plus que ma valeur en tant que CTO réside dans le fait d’avoir les réponses. Elle réside dans le fait de poser de meilleures questions, de fournir du contexte, de faire des compromis, de faire preuve de discernement et de créer un environnement dans lequel les humains et les machines se rendent mutuellement meilleurs.

Cela exige de l’humilité. L’IA identifiera parfois une approche à laquelle je n’avais pas pensé. Un ingénieur junior doté de solides compétences en IA peut remettre en question une hypothèse qu’une personne ayant 25 ans d’expérience considère comme évidente. Je pense que les grands leaders technologiques doivent accueillir cette possibilité.

Le CTO de l’ère de l’IA ne peut pas simplement être la personne la plus compétente techniquement dans la salle. Nous devons devenir ceux qui conçoivent la salle. Qui a voix au chapitre ? Que peut décider l’IA ? Dans quels domaines le jugement humain reste-t-il essentiel ? Comment savons-nous lorsque nous avons tort ?

Voilà la transformation du leadership.

Pourquoi les CTO doivent se méfier des gains d’efficacité

Mon principal conseil aux CTO en ce moment est le suivant : ne confondez pas rapidité d’exécution et progrès.

Les leaders technologiques subissent une pression considérable pour « faire quelque chose avec l’IA ». Les conseils d’administration posent des questions à ce sujet. Les PDG posent des questions à ce sujet. Les employés l’utilisent déjà, que vous ayez une politique en la matière ou non. Tous les fournisseurs ont soudain découvert que leur produit avait toujours été « alimenté par l’IA ».

Il est très facile de devenir réactif. Mais je pense que le rôle du CTO consiste actuellement à instaurer de la clarté au milieu de tout ce bruit.

• Premièrement, utilisez vous-même la technologie. Et je veux dire : utilisez-la vraiment. Ne construisez pas votre stratégie d’IA uniquement à partir de rapports d’analystes et de démonstrations de fournisseurs. J’utilise des outils comme ChatGPT, Claude et GitHub Copilot parce que j’ai besoin d’une expérience directe de leurs points forts exceptionnels, de leurs échecs et de la rapidité avec laquelle ces limites évoluent. Vous ne pouvez pas diriger efficacement une transition technologique que vous ne vivez qu’à travers PowerPoint.
• Deuxièmement, partez des contraintes de l’entreprise, et non des capacités de l’IA. Je m’intéresse beaucoup moins à la question « Où pouvons-nous utiliser l’IA générative ? » qu’à celle-ci : « Dans quels domaines sommes-nous lents, coûteux, incohérents, limités en capacité ou sources de frustration pour nos clients ? » Je peux ensuite déterminer si l’IA a réellement sa place dans la solution.
• Troisièmement, renforcez vos fondations. L’IA ne sauvera pas des données de mauvaise qualité, des API fragiles, une observabilité insuffisante, une documentation inexistante ou des pratiques d’ingénierie dysfonctionnelles. Elle les amplifiera souvent. L’IA agit comme un amplificateur de l’organisation et du système technique sous-jacents.
• Quatrièmement, concevez une gouvernance fondée sur les conséquences, et non sur la peur. Je ne veux pas d’une politique d’IA de 47 pages qui revient en pratique à dire : « Veuillez ne rien faire d’intéressant. » Je veux des contrôles proportionnels aux risques. Laissez les équipes expérimenter énergiquement lorsque les actions sont réversibles et peu lourdes de conséquences. Renforcez la supervision humaine à mesure que les décisions commencent à avoir une incidence sur les données clients, l’argent, la sécurité, les obligations réglementaires ou les systèmes de production.
• Cinquièmement, et c’est peut-être le point le plus important, repensez le travail au lieu de vous contenter d’y ajouter de l’IA. Si mon processus de développement comporte douze étapes et que l’IA accélère la quatrième de 70 %, je n’ai pas transformé l’ingénierie. J’ai accéléré la quatrième étape.
• Et enfin, protégez le jugement humain tout en éliminant résolument les tâches fastidieuses.

Je pense que les CTO disposent actuellement d’une occasion rare. Ne vous demandez pas seulement comment l’IA rend votre organisation actuelle plus efficace. Demandez-vous quelle organisation vous construiriez si vous commenciez aujourd’hui. C’est la question la plus inconfortable. C’est aussi celle qui distinguera les entreprises qui se contentent d’utiliser l’IA de celles qui se transforment réellement grâce à elle.

Suivez l’actualité

Vous pouvez suivre le travail de Tyrone Grandison sur LinkedIn et son site web personnel. Vous pouvez également consulter ses livres, La révolution de l’IA et Une culture qui perdure.

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