Le directeur mondial de l’architecture de l’IA affirme que l’IA constitue un changement de modèle opérationnel, et non un simple déploiement d’outils

Manish Jain est vice-président et responsable mondial de l’architecture de l’IA chez Firstsource, où il dirige une équipe de 50 personnes. Il se concentre actuellement sur la création de systèmes agentiques capables de gérer des tâches en plusieurs étapes.

Nous nous sommes entretenus avec Manish pour comprendre comment l’IA transforme son modèle opérationnel. Voici ce qu’il nous a dit.

Du potentiel à une capacité prête pour la production

Je m’appelle Manish Jain et je suis un responsable de l’IA et des technologies qui s’attache à aider les organisations à transformer le potentiel de l’IA en capacités fiables et prêtes pour la production. J’ancre mon travail dans la réalité concrète de la transformation. J’ai dirigé de nombreuses initiatives liées à l’IA et au ML au cours des dernières années, travaillé en étroite collaboration avec des équipes métier et participé à des projets d’ingénierie et de déploiement dans lesquels la réussite dépend de bien plus que du choix du bon modèle. L’architecture, la qualité des données, la sécurité, l’intégration, l’adoption par les utilisateurs et une valeur métier clairement définie doivent tous être réunis.

Je dirige actuellement des initiatives d’IA au sein d’une organisation interfonctionnelle d’environ 50 personnes, comprenant des ingénieurs logiciels et des ingénieurs de plateformes, des spécialistes de l’IA et des données, des responsables produit, des partenaires de la sécurité et des experts des domaines métier. Le travail couvre la mise en œuvre de l’IA en entreprise et la fourniture de solutions directement sur le terrain. Les équipes travaillent en étroite collaboration avec les clients et les parties prenantes internes afin de faire passer les cas d’usage à forte valeur ajoutée de la phase de découverte à un déploiement sécurisé et évolutif en production.

Notre approche est volontairement indépendante du cloud et des modèles. Nous déployons principalement sur Azure et AWS, et utilisons Google Cloud de manière sélective en fonction de l’environnement du client, de son patrimoine de données et de ses besoins opérationnels. Plutôt que de concevoir nos solutions autour d’un fournisseur cloud ou d’un modèle de fondation unique, nous construisons des architectures modulaires qui nous permettent de choisir et de faire évoluer les composants sous-jacents au gré des changements d’exigences. Cela inclut la couche de modèles, les services de recherche et de données, le cadre d’orchestration, les outils d’évaluation, l’observabilité et les contrôles de sécurité.

La véritable complexité ne réside pas simplement dans le choix d’un LLM. Elle consiste à intégrer l’IA aux flux de travail métier répartis entre des sources de données fragmentées, des applications anciennes, des autorisations utilisateur variables et des exigences strictes en matière de sécurité, de fiabilité, de coûts et de conformité. Nous commençons généralement par un cas d’usage ciblé et une évaluation rigoureuse, puis mettons en production ce qui fonctionne grâce à des garde-fous, à une supervision humaine lorsque cela est approprié, à une surveillance continue et à des itérations permanentes. L’objectif est de créer des capacités d’IA qui restent adaptables à mesure que la technologie évolue et suffisamment fiables pour que les équipes puissent s’y appuyer au quotidien.

Je m’intéresse particulièrement au passage des copilotes individuels aux systèmes agentiques capables de gérer des tâches en plusieurs étapes dans des limites définies. Pour les responsables technologiques, l’opportunité est importante, mais sa concrétisation exige une ingénierie rigoureuse, une gouvernance réfléchie et une forte attention portée aux résultats.

Pourquoi une mise en œuvre de l’IA axée d’abord sur l’évaluation améliore les résultats

Au cours de l’année écoulée, j’ai fait évoluer la mise en œuvre de l’IA, passant d’un état d’esprit axé d’abord sur les prototypes à une discipline d’ingénierie axée d’abord sur l’évaluation. Il y a un an, les équipes construisaient souvent rapidement des preuves de concept impressionnantes en connectant des flux de travail à des modèles uniques. Mais elles prenaient souvent trop tard en compte les facteurs qui déterminent la fiabilité de l’IA en production — qualité, ancrage, contrôle des accès, gestion des défaillances, coûts et responsabilité des utilisateurs.

Nous avons mis en place un modèle de mise en œuvre commun dans lequel chaque cas d’usage de l’IA commence par une définition claire de la réussite, des données d’évaluation représentatives, un examen de la sécurité et de l’accès aux données, une traçabilité et une surveillance continue. Nous avons également conçu l’architecture sous-jacente pour qu’elle soit indépendante du cloud et des modèles. Cela permet aux équipes d’évaluer la combinaison adéquate de modèles, d’approches de recherche et de schémas d’orchestration pour chaque flux de travail, sans enfermer le produit dans un fournisseur ou une génération de modèles unique.

Concrètement, cela s’est traduit par moins de retouches et une plus grande confiance dans les déploiements en production. Les équipes peuvent identifier les régressions de qualité ou de coûts avant qu’elles n’affectent les utilisateurs, prendre des décisions explicites quant aux situations nécessitant un examen humain et améliorer les systèmes sur la base de données probantes plutôt que de retours anecdotiques.

À l’avenir, je pense que cela constitue le fondement d’une IA agentique responsable. À mesure que les systèmes dépassent le stade des réponses aux questions et commencent à effectuer des actions en plusieurs étapes dans les flux de travail de l’entreprise, nous ne pouvons pas ajouter l’évaluation, l’observabilité, les autorisations et la gouvernance après coup. Ces éléments doivent faire partie intégrante de l’ingénierie dès le premier jour.

Comment les humains gagnent en importance avec l’ingénierie agentique

Nous utilisons l’IA tout au long du cycle de vie des produits. Lors de la découverte, elle transforme les contributions des parties prenantes, les retours des clients et la documentation existante en premières exigences, récits utilisateurs, critères d’acceptation et questions techniques. En ingénierie, elle facilite l’exploration des bases de code, la documentation, l’implémentation, la refactorisation, la préparation des demandes d’extraction et la génération de tests. En exploitation, elle résume les journaux, met en corrélation les alertes avec les versions récentes, récupère le contexte des incidents précédents et réduit le champ des recherches pendant le triage. Les équipes consacrent moins de temps à rassembler le contexte entre les outils et davantage à valider les décisions, résoudre les problèmes complexes et faire progresser la mise en œuvre.

Nous conservons sous responsabilité humaine la propriété de l’architecture, la validation de la sécurité, les décisions relatives à l’accès aux données, l’approbation des mises en production et les arbitrages de priorités. Ces décisions nécessitent un contexte métier, une responsabilité et une compréhension des conséquences qui vont au-delà de ce que peuvent contenir un ticket, une invite ou un dépôt de code. L’IA peut analyser les différentes options, identifier les dépendances, signaler les problèmes de sécurité et rassembler les éléments probants, mais c’est un ingénieur ou un responsable qui prend la décision.

Nous faisons délibérément cette distinction à mesure que nous évoluons vers une ingénierie davantage agentique. Je m’attends à ce que l’IA prenne en charge davantage d’exécutions délimitées, comme l’implémentation de changements bien définis, la génération et l’exécution de tests, la validation des critères de déploiement ou la proposition d’étapes de remédiation après incident. À mesure que cela se produit, le rôle humain devient plus important, et non moins. Les ingénieurs définissent l’intention, les autorisations, les seuils de qualité et les limites de restauration, puis vérifient si le système a atteint le résultat attendu.

Comment l’IA alimente efficacement les flux de travail d’ingénierie de bout en bout

Voici notre flux de travail de bout en bout, qui fait passer une demande produit bien définie par la conception, l’implémentation, la validation et la mise en production. Il commence lorsqu’un responsable produit et un responsable de l’ingénierie définissent le résultat attendu pour le client, les contraintes et les critères d’acceptation. L’IA synthétise ensuite le contexte métier pertinent, la documentation existante, les modèles architecturaux et les dépendances afin de produire une première version de la conception technique, du plan d’implémentation et de la stratégie de test. Un ingénieur examine ce plan, prend les décisions d’architecture et décompose le travail en petits changements pouvant être vérifiés indépendamment.

Pendant l’implémentation, les ingénieurs utilisent l’IA au sein de la base de code pour comprendre les services concernés, générer une première version du code et des changements de configuration, mettre à jour la documentation et créer des tests unitaires et d’intégration. Chaque changement passe toujours par le contrôle de version, les vérifications CI automatisées, la revue par les pairs, l’analyse de sécurité et le processus de mise en production établi. Si un test échoue, l’IA interprète l’échec, identifie la dépendance ou la régression probable et propose une correction, mais l’ingénieur vérifie la correction avant sa mise en œuvre.

Après le déploiement, le flux de travail se poursuit. L’IA résume les journaux de l’application, met en corrélation les anomalies avec les mises en production récentes et présente à l’ingénieur d’astreinte les incidents antérieurs ou les procédures d’exploitation pertinents. Nous mesurons la boucle complète à l’aide du délai de mise en production, de la couverture des tests, du taux d’échec des changements, de la fréquence des restaurations et du délai de résolution.

Il ne s’agit pas d’un développement logiciel autonome. Il s’agit d’un système de livraison piloté par des humains et enrichi par l’IA, dans lequel l’IA accélère la collecte du contexte et l’exécution, tandis que les ingénieurs restent responsables de la conception, de la qualité, de la sécurité et du résultat en production.

Manish nous explique

L’IA a considérablement réduit le temps que les ingénieurs consacrent à la collecte du contexte et à la production de la première version des tâches courantes. Elle aide les équipes à passer plus rapidement d’une exigence initiale à une approche technique structurée, à l’implémentation, à la couverture des tests et à la documentation.

Comment l’IA améliore la fluidité entre les fonctions

En ce qui concerne les résultats, l’IA a considérablement réduit le temps que les ingénieurs consacrent à la collecte du contexte et à la production de la première version des tâches courantes. Elle aide les équipes à passer plus rapidement d’une exigence initiale à une approche technique structurée, à l’implémentation, à la couverture des tests et à la documentation. Elle a accéléré le développement de nouvelles fonctionnalités et capacités produit, en particulier lorsque les ingénieurs doivent analyser une base de code qui leur est inconnue, suivre des dépendances ou travailler sur plusieurs services.

L’IA contribue également aux décisions d’architecture. Elle peut rapidement synthétiser la documentation système existante, identifier les dépendances, comparer les options d’implémentation, faire ressortir les arbitrages probables et aider les équipes à créer des dossiers de décision d’architecture. Les humains prennent les décisions finales en matière d’architecture, mais les équipes abordent ces discussions avec un meilleur contexte. Elles peuvent consacrer davantage de temps à débattre des décisions qui comptent réellement, comme l’évolutivité, la résilience, la sécurité, les coûts et la maintenabilité à long terme.

L’amélioration ne se résume pas à une génération de code plus rapide. Nous constatons une meilleure fluidité tout au long du cycle de vie, car les équipes produit, d’ingénierie, d’assurance qualité et d’exploitation commencent avec un contexte plus complet et plus cohérent. Les ingénieurs consacrent davantage de temps à la conception des systèmes, aux cas limites, à la complexité des intégrations et à l’impact client, plutôt qu’à rassembler manuellement des informations provenant des dépôts, des tickets, des tableaux de bord, des journaux et des incidents passés.

Comment mesurer la réussite avec l’IA

Nous avons également tiré d’importantes leçons des inconvénients. L’IA peut créer une fausse impression de rapidité lorsque les équipes acceptent des résultats plausibles sans validation suffisante. Elle peut générer du code qui semble correct, mais qui ne s’intègre pas à l’architecture environnante, ignore des règles métier subtiles, introduit une complexité inutile ou crée des problèmes de sécurité et de maintenabilité. Les gains de productivité sont également inégaux. Les ingénieurs qui comprennent le système, formulent précisément leurs demandes et valident rigoureusement les résultats sont ceux qui en bénéficient le plus.

C’est pourquoi nous mesurons la réussite à travers la qualité des livraisons plutôt qu’à l’aide de métriques d’activité liées à l’IA. Les résultats qui nous importent sont une livraison plus rapide des fonctionnalités, des cycles plus courts, des mises en production stables, une meilleure couverture de tests, une réduction des reprises, une résolution plus rapide des incidents et une fiabilité durable. Les perspectives à long terme sont considérables, mais uniquement si l’IA améliore le jugement et l’exécution des ingénieurs au lieu de se substituer à l’un ou à l’autre.

Comment les nouvelles contraintes transforment la structure des équipes

La génération de code n’est plus la contrainte qui limite la vélocité des équipes d’ingénierie. Les véritables contraintes sont souvent des exigences floues, un contexte métier fragmenté, des dépendances architecturales, les revues de sécurité, l’intégration entre les systèmes et le temps nécessaire pour valider qu’une modification fonctionne de manière sûre en production. Les données du secteur vont dans le même sens : le codage représente une part relativement faible de la journée d’un ingénieur, et l’adoption de l’IA pour coder ne se traduit pas automatiquement par des gains de débit proportionnels.

Cela a changé ma façon de concevoir la structure des équipes. Plutôt que de considérer simplement l’IA comme un moyen de réduire l’effort de livraison, nous évoluons vers des équipes plus réduites et plus transversales, assumant davantage la responsabilité du processus allant de la découverte à l’apprentissage en production. Les ingénieurs doivent consacrer moins de temps à produire les premières versions et davantage à définir l’intention, concevoir l’architecture, valider les résultats et améliorer le système après sa mise en production.

En outre, notre approche du recrutement s’est éloignée de la simple production de code pour privilégier la pensée systémique, le discernement produit et la validation du travail assisté par l’IA. Nous apprécions les ingénieurs capables de gérer l’ambiguïté, de faire des compromis pertinents en matière d’architecture et de sécurité, et d’assumer la responsabilité des résultats en production.

Manish nous dit

\u003cstrong\u003eL’avenir ne se résume pas à une mise en œuvre plus rapide. Il s’agit d’un alignement plus rapide et d’une boucle plus étroite entre une idée, un résultat en production et les enseignements qui éclairent la décision suivante.\u003c/strong\u003e

L’avenir ne se résume pas à une mise en œuvre plus rapide. Il s’agit d’un alignement plus rapide et d’une boucle plus étroite entre une idée, un résultat en production et les enseignements qui éclairent la décision suivante.

Pourquoi les tests doivent être repensés pour un avenir augmenté par l’IA

Les tests doivent être repensés.

L’IA permet de créer du code beaucoup plus rapidement, ce qui signifie que l’assurance qualité doit devenir continue, automatisée et intégrée au flux de livraison, plutôt que d’être considérée comme une étape finale de validation. Les équipes ont besoin d’une génération de tests assistée par l’IA, de jeux de données d’évaluation réalistes, de contrôles de sécurité et de performance, d’une surveillance en production et d’une responsabilité humaine clairement définie pour les exceptions.

Dans un cycle de vie augmenté par l’IA, l’avantage concurrentiel ne reviendra pas à ceux qui génèrent du code le plus rapidement, mais à ceux qui peuvent valider les modifications en toute sécurité et tirer le plus rapidement les enseignements de la production.

Comment éviter rapidement les frictions liées à l’IA

Nous avons sous-estimé les réalités opérationnelles de l’IA. La consommation de jetons et les limites d’utilisation peuvent fortement restreindre la livraison, en particulier pour les flux de travail de codage agentique qui nécessitent le contexte d’importantes bases de code ou des itérations répétées. Nous considérons désormais les dépenses liées à l’IA comme une décision concernant la capacité d’ingénierie, avec une visibilité sur l’utilisation, le routage des modèles, la gestion du contexte et la valeur produite — et pas seulement sur le coût des licences. La fiabilité des services est également importante. Un modèle externe ou une plateforme de codage peut rencontrer des problèmes de latence, de limitation du débit ou de disponibilité ; les flux de travail critiques doivent donc prévoir des modèles de secours, une dégradation progressive et des moyens permettant aux ingénieurs de continuer à travailler sans le service d’IA.

Nous aurions pu éviter les premières frictions en définissant dès le départ les outils approuvés, des limites claires concernant les données, les attentes en matière de revue, les contrôles des coûts et des mécanismes de secours.

Je ne rendrais pas non plus obligatoire un outil ou un flux de travail unique trop tôt. La technologie évolue trop rapidement. La meilleure approche consiste à fournir un accès sécurisé, des garde-fous réutilisables, des possibilités d’apprentissage entre pairs et une responsabilisation claire. Un ingénieur reste responsable de ce qu’il conçoit, examine, fusionne et exploite en production.

Pourquoi l’IA doit être considérée comme une évolution du modèle opérationnel

Mon conseil aux CTO est de considérer l’IA comme une évolution du modèle opérationnel, et non comme le déploiement d’un outil. Commencez par un petit nombre de flux de travail à forte valeur ajoutée, pour lesquels vous pouvez établir une base de référence, mesurer l’impact et apprendre rapidement. Mettez en place une plateforme d’IA partagée et une discipline de mise en œuvre autour de modèles approuvés, d’un accès sécurisé aux données, de l’évaluation, de l’observabilité et de modèles d’intégration réutilisables, tout en conservant une architecture indépendante du cloud et des modèles. Cela évite à chaque équipe de réinventer les mêmes contrôles ou de devenir trop tôt dépendante d’un fournisseur.

Tout aussi important, investissez dans les personnes. Les organisations qui en tireront le plus grand bénéfice ne seront pas celles qui se contenteront de générer davantage de code. Ce seront celles qui aideront les ingénieurs, les équipes produit, les partenaires de la sécurité et les dirigeants d’entreprise à apprendre à définir clairement le travail, à valider les résultats de l’IA et à exploiter des systèmes agentiques dans des limites définies. Avancez avec détermination, mais faites de la confiance, de la qualité, de la sécurité et des résultats mesurables des exigences non négociables.

L’IA devient une couche d’exécution essentielle pour l’entreprise ; le rôle du CTO consiste donc à créer l’architecture, la gouvernance et la culture qui lui permettent de se développer de manière responsable.

Suivez son actualité

Vous pouvez suivre les travaux de Manish Jain sur son Substack et sur LinkedIn.

D’autres entretiens avec des experts seront bientôt publiés sur The CTO Club !