Les enseignements du CTO Circle : comment les leaders de l’ingénierie bâtissent des entreprises pensées pour l’IA

À mesure que l’IA change les règles du jeu, tous les leaders de l’ingénierie cherchent à répondre aux mêmes questions : Comment organiser les équipes d’ingénierie ? Dans quels domaines les entreprises doivent-elles investir alors que les modèles de fondation continuent de progresser ? Comment accélérer le rythme de l’ingénierie sans introduire un niveau de risque opérationnel inacceptable ? Quelle est la différence entre les entreprises augmentées par l’IA et celles qui sont pensées pour l’IA ? 

Il n’existe encore aucune feuille de route établie pour créer une organisation d’ingénierie pensée pour l’IA, et les occasions pour les leaders de l’ingénierie de comparer ouvertement leurs apprentissages sont rares. Ces échanges restent souvent cantonnés au sein de chaque entreprise, façonnés par les pressions concurrentielles et une technologie qui évolue rapidement. 

En tant que plateforme sur laquelle des milliers d’entreprises élaborent leurs stratégies data et d’intelligence artificielle, Snowflake est idéalement positionné pour réunir ces acteurs. CTO Circle a été créé pour offrir aux leaders de l’ingénierie un espace de confiance où apprendre de pairs confrontés à la même transformation et remettre en question les idées reçues. Organisé pendant le Snowflake Summit 2026 à San Francisco, le premier événement a réuni plus de 350 CTO issus de secteurs variés, notamment des services financiers, des télécommunications, du retail et de la technologie, afin de partager des enseignements concrets. 

La discussion est allée bien au-delà des assistants de codage et du choix des modèles. Elle s’est concentrée sur la refonte des organisations d’ingénierie, les pratiques qui fonctionnent en production et les domaines dans lesquels les leaders investissent pour créer un avantage concurrentiel durable. Les échanges ont convergé autour de trois thèmes qui définissent ce que signifie bâtir une organisation d’ingénierie pensée pour l’IA : utiliser l’IA en production, concilier rapidité et maîtrise des risques, et concevoir des équipes d’ingénierie pour l’IA.

De nombreuses organisations commencent leur parcours vers l’IA en intégrant des assistants de codage à leurs workflows d’ingénierie existants. Les développeurs écrivent du code un peu plus vite et produisent plus facilement la documentation. Ces améliorations sont importantes, mais elles laissent le système d’ingénierie sous-jacent largement inchangé.

Vivek Raghunathan, SVP of Engineering chez Snowflake, a invité les leaders à envisager l’adoption de l’IA dans une perspective bien plus large. Selon Vivek, bâtir une organisation d’ingénierie pensée pour l’IA commence par faire évoluer la philosophie de management. Plutôt que de considérer la productivité des développeurs comme un problème d’ingénierie ou de culture, Snowflake a commencé à la traiter comme un produit.

« Et si vous traitiez vos développeurs comme des clients ? » Cette question est devenue le fondement de l’approche adoptée par Snowflake pour sa propre transformation de l’ingénierie. Plutôt que de supposer que la direction savait ce dont les ingénieurs avaient besoin, l’équipe a appliqué les mêmes principes de gestion des produits que ceux utilisés pour créer des produits destinés aux clients. 

Elle a interrogé les développeurs pour comprendre où le travail ralentissait et cartographié les points de friction tout au long du cycle de vie du développement logiciel. L’équipe a ensuite défini des métriques de référence et mené des expériences pour mesurer l’impact de chaque changement. Cette approche associait un soutien clair de la direction à une adoption ascendante. Elle a ainsi permis de veiller à ce que les améliorations reflètent la façon dont les ingénieurs travaillaient réellement, plutôt que celle que les leaders imaginaient.

Les résultats étaient mesurables. En 18 mois, Snowflake a augmenté de plus de 30 points son Net Promoter Score interne auprès des développeurs. Sur cette période, le ratio entre développeurs satisfaits et insatisfaits a atteint 4:1. Plus important encore, cette progression s’est traduite par une organisation d’ingénierie capable de livrer des logiciels plus efficacement et de s’adapter plus rapidement à mesure que les capacités de l’IA évoluaient.

Vivek a également expliqué que l’adoption seule ne suffit pas à générer des gains de productivité significatifs. Le véritable effet de levier vient de la profondeur d’utilisation et de la maîtrise réelle des outils à grande échelle. Chez Snowflake, ce parcours s’est structuré en trois étapes :

• Adoption : commence lorsque les développeurs apprennent à utiliser les outils d’IA dans leur travail quotidien. 
• Maîtrise : se développe lorsque les ingénieurs découvrent des workflows reproductibles qui produisent systématiquement de meilleurs résultats. 
• Optimisation : intervient lorsque ces workflows deviennent des connaissances collectives dont chaque ingénieur peut tirer parti.

Les modèles de conception d’ingénierie développés en interne chez Snowflake en sont un exemple. Les premiers utilisateurs de l’IA ont expérimenté différentes techniques de prompting, méthodes de planification et approches de débogage. Au fil du temps, l’organisation a documenté les modèles qui produisaient systématiquement de meilleurs résultats et les a mis à disposition de toutes les équipes d’ingénierie. 

Chaque développeur avait accès aux mêmes outils d’IA, mais les ingénieurs qui s’appuyaient sur des workflows éprouvés obtenaient systématiquement de meilleurs résultats que ceux restés aux premiers stades de l’adoption des outils. L’avantage concurrentiel venait de l’institutionnalisation des méthodes de travail efficaces, et non du simple déploiement d’un nouvel assistant d’IA.

Cette approche centrée sur les workflows change également la manière dont les entreprises envisagent le développement logiciel lui-même. À mesure que l’IA réduit les efforts nécessaires pour transformer des idées en logiciels fonctionnels, chacun devient un builder. Les product managers peuvent prototyper de nouvelles expériences, les designers valider directement leurs concepts dans le code et les experts métier ajouter des garde-fous pour d’autres personas. Plutôt que de débattre des idées au fil de présentations ou de documents, les équipes peuvent les valider en créant des logiciels fonctionnels. Le code devient de plus en plus le moyen le plus rapide de tester des hypothèses.

Jon McNeill, auteur de The Algorithm, a approfondi cette réflexion en invitant les leaders à remettre en question les hypothèses qui façonnent les organisations d’ingénierie depuis des décennies. Trop souvent, les entreprises commencent par la technologie avant de chercher où l’appliquer. Jon a soutenu que les organisations performantes inversent cette logique. Elles commencent par identifier les quelques contraintes business les plus importantes, puis repensent leurs systèmes d’ingénierie pour résoudre ces problèmes. À mesure que les entreprises passent l’IA en production, leur réussite se mesurera moins à la quantité de code générée ou de tokens consommés qu’à leur capacité à construire le système d’ingénierie le plus simple, le plus rapide et le plus efficace. Le classement le plus intéressant ne réunira peut-être pas les ingénieurs qui génèrent le plus de code avec l’IA ou consomment le plus de tokens. Il mettra plutôt à l’honneur ceux qui ont éliminé le plus d’étapes inutiles entre une idée et sa mise en production.

À mesure que l’IA s’intègre à toutes les étapes du cycle de vie du développement logiciel, les leaders de l’ingénierie doivent relever un deuxième défi. Chaque gain de vélocité dans le développement renforce également le besoin de systèmes fiables et de rigueur opérationnelle. Les organisations qui avancent le plus vite investissent dans des architectures qui rendent ces deux objectifs compatibles.

Jeremy Burton, General Manager de l’unité commerciale Observability chez Snowflake, estime que l’IA est entrée dans une nouvelle phase. L’expérimentation initiale cède la place au déploiement en production, et les entreprises doivent de plus en plus démontrer une valeur business mesurable plutôt que de simples réussites techniques isolées. Dans le même temps, l’IA introduit des défis opérationnels totalement nouveaux. Les agents d’IA génèrent davantage de données de télémétrie, interagissent avec un plus grand nombre de systèmes et prennent des décisions à partir d’informations réparties dans des environnements toujours plus complexes. Cette évolution fait passer l’observabilité du simple suivi de l’infrastructure à la fourniture du contexte dont les systèmes d’IA ont besoin pour fonctionner de manière fiable.

Jeremy a remis en question l’une des idées les plus répandues dans le domaine de l’IA d’entreprise : il suffirait de fournir de meilleures données à de meilleurs modèles. En réalité, l’efficacité de l’IA dépend entièrement du contexte auquel elle peut accéder. Ce contexte va bien au-delà des données de télémétrie brutes. Il comprend la sémantique qui décrit la signification des données, les relations capturées au moyen d’ontologies et de graphes de connaissances, ainsi que le contexte business qui relie les systèmes entre eux. La manière dont ce contexte est accessible est tout aussi importante. Les agents d’IA ont besoin d’interfaces standardisées, telles que des API, des CLI et le Model Context Protocol (MCP), pour récupérer les informations de manière fiable et agir sur celles-ci. Les ingénieurs, quant à eux, ont besoin de moyens intuitifs pour explorer les données en profondeur et valider les insights générés par l’IA. 

Un contexte riche associé à un accès ouvert transforme une télémétrie fragmentée en un environnement où les humains comme l’IA peuvent raisonner efficacement, analyser les problèmes plus rapidement et prendre de meilleures décisions. Les entreprises qui continuent de stocker leurs logs, métriques, traces, données opérationnelles et contexte business dans des systèmes cloisonnés empêchent l’IA de raisonner avec précision sur les environnements de production. La télémétrie d’ingénierie doit au contraire être traitée comme des données intégrées à une fondation commune, où les relations entre les systèmes peuvent être comprises et interrogées.

Aditya Gaur, Engineering Manager chez Netflix, a montré concrètement à quoi cela ressemble à travers le travail de l’entreprise sur l’analyse automatisée des causes racines. Bien que le projet soit souvent présenté comme une initiative d’IA, Aditya a expliqué que sa réussite reposait bien davantage sur l’architecture de données que sur l’IA elle-même. 

Des années avant d’introduire des agents d’IA, Netflix a investi dans la connexion de données de télémétrie fragmentées entre les systèmes, la modélisation des relations opérationnelles au moyen d’une ontologie et d’un graphe de connaissances, ainsi que la création d’une couche de contexte partagé. Lorsque l’IA est entrée en scène, les fondements étaient déjà en place. Plutôt que de rechercher des informations dans des logs et des tableaux de bord cloisonnés, les agents d’IA pouvaient raisonner à partir de connaissances opérationnelles structurées et générer des hypothèses bien plus pertinentes lors des investigations d’incidents.

Caitlin Colgrove, CTO chez Hex, a abordé la vélocité sous un angle différent. Elle a invité les leaders à repenser ce que signifie avancer vite à l’ère de l’IA. Les entreprises ne peuvent pas se permettre d’être seulement partiellement pensée pour l’IA. Elles finissent par atteindre un point où elles doivent s’engager pleinement, en repensant la manière dont les équipes construisent des produits, prennent des décisions et intègrent l’IA dans leur travail quotidien. Elle a décrit cette démarche comme le fait de « brûler les bateaux ». L’IA doit devenir un fondement du fonctionnement de l’entreprise. 

Hex a d’abord réagi à l’arrivée de l’IA générative en créant une équipe produit dédiée à l’IA. Si cette approche a permis de proposer des fonctionnalités utiles, elle a également créé un goulot d’étranglement organisationnel. Hex a finalement dissous son organisation IA centralisée et réparti les responsabilités entre toutes les équipes produit. Aujourd’hui, Hex fournit rapidement ses produits et intègre des fonctionnalités d’IA dans l’ensemble de son offre, car la responsabilité revient aux ingénieurs les plus proches des problématiques des clients.

Chris Kozlowski, Managing Director chez Barclays, a apporté une perspective d’entreprise à la discussion et souligné que la vitesse ne crée de la valeur que lorsqu’elle s’accompagne de gouvernance et de confiance. Dans les environnements fortement réglementés, les équipes d’ingénierie ne peuvent pas choisir entre innovation et contrôle.

Corey Burke, SVP Engineering chez Dialpad, et Arun Rajamanickam, VP of Engineering chez project44, ont décrit comment l’IA accélère le développement logiciel. À mesure que les agents d’IA deviennent capables d’implémenter de manière autonome des pans importants d’une feature, les ingénieurs consacrent moins de temps à écrire du code et davantage à définir l’intention, orchestrer plusieurs agents et valider les résultats. 

Ils ont souligné que maximiser la vitesse de développement exige de créer des plateformes d’ingénierie qui permettent aux équipes d’expérimenter rapidement sans compromettre la fiabilité. L’IA raccourcit le chemin entre l’identification d’un problème client et la validation d’une solution, mais uniquement si les équipes disposent de l’infrastructure, du contexte partagé et de la discipline opérationnelle nécessaires pour itérer en toute confiance.

Si l’IA transforme la façon dont les logiciels sont développés, elle transforme inévitablement aussi la manière dont les organisations d’ingénierie sont structurées. Elle impose de nouvelles structures d’équipe, de nouveaux modèles de leadership et une compréhension différente de la manière dont les ingénieurs créent le plus de valeur.

Qi Jin, EVP chez Cerebras Systems, a avancé que les organisations optimisées pour les précédentes générations de développement logiciel constituent souvent le principal frein à l’adoption de l’IA. Les processus établis et les frontières organisationnelles ont été conçus pour faire évoluer des méthodes de travail éprouvées, et non pour s’adapter en continu aux technologies de rupture. Adopter l’IA avec succès exige donc bien plus que l’introduction de nouveaux outils. Les leaders doivent repenser leurs modèles opérationnels afin que les équipes puissent rapidement intégrer de nouvelles fonctionnalités à mesure que la technologie évolue. 

Qi a décrit cette transformation à travers le concept de « Code Yellow », un framework destiné à accélérer le changement organisationnel en se concentrant sur les problèmes des clients. Sa vision fait écho à une philosophie plus large du leadership, qu’il a développée dans son essai consacré au « manager en temps de guerre ». Il y défend l’idée que les périodes de bouleversements rapides exigent des leaders capables de simplifier la prise de décision, d’agir avec détermination et de remettre en question les normes établies plutôt que d’optimiser les processus existants.

Parvez Naqvi, Managing Vice President of Cloud Platforms, Resilience Engineering and Enterprise Architecture chez Capital One, a expliqué plus en détail comment ces changements organisationnels redéfinissent le rôle des ingénieurs eux-mêmes. À mesure que l’IA accélère considérablement la mise en œuvre, la valeur de l’ingénierie se déplace vers les décisions que l’IA ne peut pas prendre de manière autonome. Les principaux freins à la mise à disposition des logiciels sont désormais la planification, la conception architecturale et le discernement des ingénieurs. 

Les processus traditionnels de revue, conçus autour de code écrit manuellement, commencent à montrer leurs limites, car l’IA accélère considérablement le développement. Les ingénieurs seniors créent de plus en plus d’effet de levier en définissant l’orientation technique et en établissant des modèles architecturaux. Ils participent également davantage à la conception des systèmes et fournissent le contexte qui permet aux ingénieurs comme aux agents d’IA de prendre de meilleures décisions.

Cette évolution renforce également l’importance des plateformes pour développeurs et de l’infrastructure d’ingénierie. Les outils internes et les systèmes de déploiement deviennent des actifs stratégiques, car ils réduisent la charge opérationnelle et permettent aux équipes de se concentrer sur la conception de systèmes résilients plutôt que sur la gestion de tâches répétitives. À mesure que les product managers, les designers et les experts métier contribuent directement à la création de logiciels, les organisations d’ingénierie deviennent de plus en plus les garantes de la qualité, de l’architecture et de l’excellence opérationnelle, plutôt que les seules productrices de code.

Harjot Gill, CEO chez CodeRabbit, a expliqué comment l’IA transforme en profondeur l’expérience des développeurs. À mesure que l’IA prend en charge une plus grande part de la mise en œuvre, les ingénieurs consacrent moins de temps à traduire les idées en code et davantage à définir l’intention, à évaluer les compromis et à façonner la conception des systèmes. Les revues assistées par l’IA peuvent aider les équipes d’ingénierie à suivre le rythme sans compromettre la conformité, la sécurité ni la maintenabilité.

Jordan Topoleski, COO chez Cursor, s’est intéressé à ce qui se passe une fois le code généré. À mesure que l’IA accélère considérablement le développement, la revue du code, la validation et le maintien de la qualité de l’ingénierie deviennent les nouveaux goulots d’étranglement. Le point de vue de Jordan a conforté l’idée que les organisations qui réussissent à changer d’échelle construisent des boucles de feedback plus performantes et des systèmes d’ingénierie qui garantissent que les logiciels générés par l’IA sont prêts pour la production.

Prises dans leur ensemble, ces discussions font émerger une transformation plus large. L’ingénierie pensée pour l’IA se définit par la rapidité avec laquelle une organisation apprend et ancre de meilleures méthodes de développement logiciel. Les entreprises qui avanceront le plus vite seront celles qui repenseront continuellement leurs organisations d’ingénierie pour tirer parti de chaque nouvelle avancée de l’IA.

Les échanges de la journée ont révélé un secteur d’activité qui a largement dépassé le stade de l’expérimentation. Même si chaque organisation se trouve à une étape différente de son parcours de transformation, les défis restent remarquablement constants. Les retours des participants ont conforté notre vision de CTO Circle. Les leaders de l’ingénierie ont régulièrement souligné l’occasion d’échanger en toute franchise avec des pairs confrontés à des décisions similaires. La valeur de l’événement résidait dans la possibilité, pour les leaders de l’ingénierie, d’avoir des conversations sans détour qu’ils ont rarement l’occasion d’avoir ailleurs. 

La perspective unique de Snowflake dans tous les secteurs a permis de réunir des organisations confrontées à des défis similaires. Cela a contribué à créer un espace de confiance où partager des enseignements concrets, plutôt que des success stories soigneusement mises en scène.

Le guide de l’ingénierie pensée pour l’IA est encore en cours d’écriture. À mesure que les modèles continuent de progresser et que les pratiques d’ingénierie évoluent avec eux, ces enseignements gagneront encore en pertinence. Nous continuerons à partager les enseignements concrets de leaders de l’ingénierie qui bâtissent des organisations pensées pour l’IA, notamment en proposant une analyse approfondie de la propre transformation de Snowflake. Si ces conversations font écho aux défis auxquels votre organisation est confrontée, nous vous invitons à découvrir notre dernier podcast, tandis que nous poursuivons notre exploration de ce qu’il faut pour construire la prochaine génération d’organisations d’ingénierie.