Le responsable mondial de l’architecture des solutions chez AWS partage son modèle de modernisation pilotée par l’IA
Saurabh Shrivastava explique comment les directeurs techniques peuvent transformer les expérimentations en IA en systèmes prêts pour la production en repensant l’ingénierie autour de la gouvernance, de la validation humaine et de la valeur métier.
Saurabh Shrivastava
Responsable mondial de l’architecture des solutions
Industrialisation: L’adoption réussie de l’IA nécessite des modèles opérationnels, une gouvernance, une architecture, des talents et une discipline produit, et non des expérimentations isolées.
Déploiement sur le terrain: L’ingénierie déployée sur le terrain introduit la modernisation par l’IA agentique dans des environnements réels, en traitant rapidement les contraintes liées aux données, au code et à la sécurité.
Modèle de confiance: Utilisez une découverte déterministe, une mise en œuvre assistée par l’IA et une validation humaine pour moderniser plus rapidement sans sacrifier la précision, la sécurité ou la responsabilité.
Maîtrise des coûts: L’économie de l’inférence est déterminante : le routage des modèles, la mise en cache, le traitement par lots, la quantification et un service optimisé peuvent réduire les coûts et améliorer la fiabilité.
Cycle de développement piloté par l’IA: Le cycle de développement piloté par l’IA repense la livraison autour de l’inception, de la construction et de l’exploitation, en intégrant des agents, des contrôles de sécurité, de l’évaluation, de l’observabilité et une amélioration continue.
Saurabh Shrivastava est responsable mondial de l’architecture des solutions et de l’ingénierie déployée sur le terrain chez Amazon Web Services, où il se concentre sur l’IA agentique et la modernisation des entreprises.
Nous nous sommes entretenus avec Saurabh pour en savoir plus sur les nouveaux modèles d’ingénierie qu’il utilise dans son travail chez AWS. Voici ce qu’il nous a confié.
Industrialiser l’IA de manière responsable
Je suis un responsable de la transformation technologique et de l’IA, avec plus de 20 ans d’expérience dans l’accompagnement des entreprises pour transformer des évolutions technologiques complexes en résultats commerciaux évolutifs. Mon parcours m’a conduit à travailler dans l’ingénierie, l’architecture d’entreprise, l’ingénierie de terrain alignée sur les produits, la transformation cloud, et désormais l’IA agentique ainsi que les modèles d’usines logicielles chez AWS.
Envie d'en avoir plus avec The CTO Club ?
Créez un compte gratuit pour terminer cet article et rejoindre une communauté de CTO et de leaders en ingénierie partageant des cadres pratiques, des outils et des conseils pour concevoir, déployer et faire évoluer des technologies alimentées par l'IA.
Have an account? Log In
Au début de ma carrière, j’ai conçu et dirigé des plateformes d’entreprise à grande échelle dans les secteurs des télécommunications, de la vente au détail, de la chaîne d’approvisionnement, de la technologie financière et de la R&D. Cela m’a permis de développer une solide compréhension de la pensée systémique, de la fiabilité, de la complexité de l’intégration et de la réalité de l’exploitation des technologies à l’échelle de l’entreprise.
Chez AWS, mon rôle s’est élargi : après avoir aidé les clients à moderniser leurs infrastructures et leurs applications, je dirige désormais l’architecture mondiale des solutions ainsi que des initiatives d’ingénierie déployée sur le terrain axées sur l’IA, la modernisation et les plateformes agentiques. J’ai travaillé avec des dirigeants d’entreprise, des partenaires, des équipes produit et des équipes d’ingénierie afin de passer de la stratégie et de l’expérimentation à des plateformes gouvernées et prêtes pour la production.
L’IA n’est plus simplement une nouvelle vague technologique. Elle transforme la manière dont les organisations développent des logiciels, dont les employés travaillent, dont les clients interagissent et dont les organisations technologiques doivent fonctionner. Le véritable défi pour les dirigeants ne consiste pas seulement à sélectionner des modèles ou des outils. Il s’agit de créer le modèle opérationnel, l’architecture, la gouvernance, les compétences et la discipline produit nécessaires pour industrialiser l’IA de manière responsable.
Diriger l’architecture des solutions AWS
En tant que responsable mondial de l’architecture des solutions et de l’ingénierie déployée sur le terrain, je dirige l’organisation mondiale d’AWS consacrée à l’architecture des solutions et à l’ingénierie déployée sur le terrain, avec un accent sur les plateformes d’IA agentique, la modernisation des entreprises et la transformation cloud à l’échelle de la production.
L’organisation opère à l’échelle de l’entreprise, en collaborant avec de grands clients internationaux, des partenaires stratégiques, des équipes produit, des équipes d’ingénierie spécialisées et des organisations régionales de terrain. Le périmètre architectural est vaste : plateformes d’IA/ML, flux de travail agentiques, fondations de données et d’analyse, modernisation des applications, infrastructures natives du cloud, sécurité, gouvernance et solutions intégrées aux partenaires.
Je dirige, accompagne et influence plus de 200 spécialistes, ingénieurs partenaires et responsables technologiques de terrain dans le monde entier. Le travail est très complexe, car nous ne construisons pas de démonstrations isolées. Nous aidons les entreprises à passer des premières idées liées à l’IA et des analyses de rentabilité de la modernisation à des plateformes reproductibles, sécurisées et prêtes pour la production, capables de s’adapter à plusieurs unités commerciales, marchés et environnements clients.
Notre modèle de déploiement combine l’ingénierie déployée sur le terrain, des mécanismes de plateforme mondiaux, une mise en œuvre dirigée par les partenaires et des boucles de rétroaction entre les équipes produit et de terrain. Mon équipe élabore des modèles réutilisables, des architectures de référence, des démonstrations destinées aux dirigeants, des guides techniques, des schémas de gouvernance et des modèles de solutions composables qui accélèrent l’adoption tout en maintenant la qualité, la sécurité et la rigueur opérationnelle.
Pourquoi un modèle d’ingénierie déployée sur le terrain est essentiel avec l’IA
J’ai mis en place un modèle d’ingénierie déployée sur le terrain pour la modernisation pilotée par l’IA l’année dernière.
À l’ère du cloud, nous disposions d’architectures de référence réutilisables, de modèles de solutions, de schémas de déploiement et de points de contrôle de la gouvernance. Ces éléments étaient nécessaires, mais insuffisants avec l’IA. Les clients rencontraient encore des difficultés pour passer de la preuve de concept à la production, car le travail le plus difficile se déroulait dans leur environnement réel : données, parc applicatif, complexité du code, contraintes de sécurité et modèle opérationnel.
J’ai donc mis en place un mécanisme FDE qui intègre les ingénieurs beaucoup plus étroitement aux charges de travail réelles des clients. Au lieu de fournir des conseils depuis l’extérieur, l’équipe FDE travaille avec les données, le code, l’architecture et les équipes de livraison du client afin d’identifier les candidats à la modernisation, de créer des ressources utilisables et de mettre la première charge de travail en production.
J’ai également introduit un modèle simple en 3-3-3 : 3 jours pour la découverte, 3 semaines pour l’évaluation et 3 mois pour mettre la première charge de travail en production. Cela a fourni aux dirigeants une trajectoire claire, de l’ambition liée à l’IA à la création de valeur mesurable.
L’impact a été considérable. Les clients ont pu accélérer leur parcours de modernisation de 2x à 4x, réduire leurs coûts jusqu’à moitié et aller au-delà des démonstrations pour obtenir un retour sur investissement concret. Plus important encore, cela a transformé les échanges avec les dirigeants. L’IA n’était plus une expérimentation secondaire ; elle est devenue un mécanisme concret pour moderniser les charges de travail réelles, améliorer la productivité des équipes d’ingénierie et créer une valeur commerciale mesurable.
Comment moderniser plus rapidement sans perdre la confiance
L’IA devient plus puissante dans les travaux liés à l’état cible : générer des options de modernisation, proposer de nouvelles architectures, définir les limites des services, élaborer des modèles de migration, écrire du code, générer des tests et accélérer la mise en œuvre. Cette partie peut être davantage probabiliste, car l’IA peut explorer différentes options et améliorer la vélocité de l’ingénierie. Mais même dans ce cas, la décision finale reste humaine.
J’utilise beaucoup l’IA pour accélérer la compréhension technique, la reconnaissance des schémas et le débit de l’ingénierie, mais je ne délègue pas la responsabilité à l’IA.
Dans les entreprises complexes, l’activité repose souvent sur des décennies de code, de dette technique, de dépendances non documentées et de règles métier intégrées. Dans cet environnement, nous avons besoin d’approches à la fois déterministes et probabilistes. On ne peut pas se fier uniquement à la découverte probabiliste par l’IA pour comprendre des systèmes essentiels à la mission.
Pour la découverte du code, l’extraction des règles métier, l’analyse des dépendances, la cartographie des fonctionnalités et l’évaluation de l’état actuel, je privilégie une approche plus déterministe. Nous avons besoin de traçabilité, de reproductibilité, de preuves et de confiance dans ce que fait le système. L’IA peut aider en résumant, en regroupant et en accélérant l’analyse, mais les fondations doivent reposer sur des faits vérifiables issus du code, des journaux, des flux de données, du comportement à l’exécution et des éléments probants de l’architecture.
L’IA devient plus puissante dans les travaux liés à l’état cible : générer des options de modernisation, proposer de nouvelles architectures, définir les limites des services, élaborer des modèles de migration, écrire du code, générer des tests et accélérer la mise en œuvre. Cette partie peut être davantage probabiliste, car l’IA peut explorer différentes options et améliorer la vélocité de l’ingénierie.
Mais même dans ce cas, la décision finale reste humaine. Les ingénieurs et les responsables qui en répondent doivent valider les choix d’architecture, la posture de sécurité, l’aptitude à la mise en production, les risques liés à la conformité, l’impact client et les compromis en matière d’investissement.
Mon modèle est donc le suivant : découverte déterministe, conception et mise en œuvre accélérées par l’IA, et validation régie par l’humain. Cette combinaison nous permet de moderniser plus rapidement sans perdre la confiance, le contrôle ni la responsabilité de l’entreprise.
Les inconvénients de l’IA dans les flux de travail d’ingénierie
Le principal résultat positif est que l’IA a considérablement raccourci le chemin entre la découverte et la mise en production lorsqu’elle est intégrée à un flux de travail d’ingénierie rigoureux.
L’IA a également accéléré la compréhension du code, l’extraction des règles métier, l’analyse des dépendances, la génération de tests, la documentation et la planification de la modernisation. Elle a réduit le temps consacré à l’analyse manuelle, permettant aux équipes d’ingénierie de se concentrer davantage sur les décisions d’architecture, la validation et l’aptitude à la mise en production.
Mais l’IA peut devenir très coûteuse très rapidement si les équipes ne conçoivent pas leur solution en tenant compte de l’économie de l’inférence. Dans les grandes entreprises comptant des millions d’utilisateurs, les coûts en jetons des modèles de pointe peuvent atteindre des millions de dollars si chaque interaction dépend de modèles de fondation externes de fournisseurs tiers sans optimisation.
Une leçon à retenir est que l’architecture de l’IA doit inclure une architecture des coûts. Pour certaines charges de travail, les entreprises devraient évaluer l’inférence hébergée en interne ou dans le cloud à l’aide de GPU ou d’accélérateurs, notamment des options telles que vLLM sur une infrastructure cloud. Cela offre un meilleur contrôle sur les coûts, la latence, les limites des données et la stratégie de mise à disposition des modèles. Des techniques comme la mise en cache KV, le traitement par lots continu, la quantification et l’optimisation des noyaux peuvent améliorer sensiblement l’utilisation des GPU et réduire le coût de l’inférence.
Le coût n’est pas le seul inconvénient. L’IA peut également créer une fausse confiance si les équipes l’utilisent sans gouvernance. Les risques comprennent une compréhension incomplète du code, des dépendances hallucinées, une couverture de tests insuffisante, des failles de sécurité et des équipes passant trop rapidement du prototype à la production.
Pourquoi l’IA peine à moderniser les systèmes existants de bout en bout
L’IA a rencontré le plus de difficultés lorsque les équipes lui demandaient de prendre des décisions techniques sans disposer d’un contexte suffisant sur le système.
Un exemple courant est la modernisation des systèmes existants. L’IA peut résumer le code, générer des idées de migration et même produire rapidement du nouveau code. Mais dans les grandes entreprises, la complexité réelle va au-delà du code. Elle englobe des décennies de règles métier, des intégrations non documentées, des traitements par lots, des dépendances entre les données, des exceptions opérationnelles, des contraintes de sécurité et des responsabilités organisationnelles. Si vous demandez à l’IA de moderniser cet environnement avec une vision partielle, elle peut produire des réponses assurées mais incomplètes.
La préparation à la mise en production est un autre domaine où elle rencontre des difficultés. L’IA peut créer très rapidement des prototypes, mais beaucoup de prototypes ne deviennent pas automatiquement des systèmes de production sécurisés, observables, résilients et rentables. Les équipes sous-estiment parfois le travail nécessaire pour les tests, la gouvernance, la réponse aux incidents, la supervision, l’évaluation des modèles, la qualité des données et la gestion du cycle de vie.
Comment les ingénieurs peuvent améliorer les produits tout en maîtrisant les coûts d’inférence et la fiabilité
Voici un exemple issu d’une grande plateforme de création de contenus multimédias et marketing, où l’IA aide les utilisateurs à passer de l’intention à des ressources numériques finalisées à l’échelle de l’entreprise.
Le flux de travail commence lorsqu’un utilisateur décrit ce qu’il souhaite créer : une campagne de lancement de produit, un contenu pour les réseaux sociaux, une présentation commerciale, un extrait vidéo ou une ressource marketing localisée. L’IA interprète l’intention de l’utilisateur, notamment l’audience, le format, le ton, les directives de marque, les ressources nécessaires, les contraintes liées au canal et les exigences de conformité.
À partir de là, la plateforme utilise un flux de travail agentique. Un agent récupère les modèles, logos, polices, couleurs et ressources de campagne approuvés par la marque. Un autre génère des textes et des variantes créatives. Un autre propose des mises en page. Un autre vérifie la conformité à la marque, l’accessibilité, les politiques et la sécurité des contenus. Une dernière couche d’orchestration assemble le résultat sous forme de ressources modifiables et l’achemine vers les flux de validation ou de publication.
À cette échelle, l’ingénierie a dû relever des défis qui ne concernaient pas uniquement la qualité des modèles, mais aussi l’économie de l’inférence, la latence, la fiabilité et la gouvernance. L’équipe a optimisé un environnement d’inférence de très grande ampleur prenant en charge environ 10 000 nœuds de calcul et près de 80 000 GPU. L’architecture combinait des capacités GPU provenant de plusieurs fournisseurs cloud et de tiers agréés, en reliant ces environnements par une couche de réseau hybride. Cela a donné à la plateforme la flexibilité de placer les charges de travail en fonction du coût, de la latence, de la disponibilité et de la localité des données.
Les humains sont restés aux commandes aux principaux points de décision. L’IA générait des options, recommandait des mises en page, rédigeait des textes et accélérait la production, mais l’utilisateur ou le responsable de la marque approuvait la ressource finale.
L’équipe a également mis en œuvre une stratégie de mise à disposition des modèles plus rigoureuse. Au lieu d’envoyer chaque requête vers le modèle de pointe le plus coûteux, la plateforme répartissait les requêtes entre des modèles adaptés à chaque usage, notamment des modèles ouverts tels que Kimi et Qwen, exécutés au moyen d’environnements optimisés comme vLLM et de configurations de type Ollama. L’équipe a également appliqué des techniques d’optimisation de l’inférence, notamment la mise en cache KV, le traitement par lots continu, la quantification, l’optimisation de la mémoire et l’optimisation au niveau des noyaux, afin d’améliorer l’utilisation des GPU et de réduire les coûts.
Les humains sont restés aux commandes aux principaux points de décision. L’IA générait des options, recommandait des mises en page, rédigeait des textes et accélérait la production, mais l’utilisateur ou le responsable de la marque approuvait la ressource finale. Les équipes d’ingénierie étaient responsables des garde-fous : sécurité, accès aux données, sélection des modèles, observabilité, latence, contrôle des coûts, vérifications de sécurité et boucles de rétroaction.
Le résultat fut un flux de travail d’IA devenu partie intégrante de l’expérience produit, et non plus un simple outil interne de productivité. Il a réduit le délai entre l’idée et la ressource, amélioré la personnalisation, accru la réutilisation des composants de marque approuvés et créé une boucle de rétroaction dans laquelle les modifications des utilisateurs et les données d’engagement amélioraient les recommandations futures. Parallèlement, l’architecture a donné à l’entreprise un contrôle bien plus important sur les coûts d’inférence, la fiabilité et la gouvernance.
Pourquoi le déploiement de l’IA exige une approche orientée produit
Le déploiement d’outils d’IA concerne moins l’adoption d’outils que la transformation du modèle opérationnel de l’ingénierie.
Au départ, de nombreuses organisations pensent que le défi consiste à donner aux ingénieurs accès à des copilotes, des assistants de programmation, des API de modèles ou des plateformes d’IA internes. Cela aide, mais ce n’est pas suffisant. Sans méthodes clairement définies, les équipes utilisent l’IA de manière incohérente. Certaines l’utilisent uniquement pour générer du code. D’autres s’en servent pour la documentation. Certaines lui accordent une confiance excessive. D’autres l’évitent parce qu’elles ne savent pas exactement quels sont les risques liés à la sécurité, à la propriété intellectuelle ou à la qualité.
Si je devais recommencer, je définirais encore plus tôt le flux de travail d’ingénierie lié à l’IA : où l’IA doit et ne doit pas être utilisée, quelles preuves sont nécessaires, ce que les humains doivent vérifier et comment les résultats sont testés, sécurisés et promus en production.
Cela aurait évité quelques problèmes. Premièrement, nous aurions pu réduire les écarts d’utilisation entre les équipes. Deuxièmement, nous aurions pu éviter une confiance mal placée dans du code ou des analyses générés par l’IA qui semblaient corrects, mais manquaient de contexte suffisant. Troisièmement, nous aurions pu mieux maîtriser les coûts dès le départ en mettant en place l’orientation des modèles, la budgétisation des jetons, la mise en cache et la gouvernance de l’inférence dès le début. Quatrièmement, nous aurions pu créer de meilleurs modèles réutilisables au lieu de laisser chaque équipe inventer sa propre approche.
La principale leçon est que le déploiement de l’IA nécessite une approche axée sur le produit et la plateforme. Il faut prévoir l’accompagnement, les garde-fous, l’observabilité, le contrôle des coûts, la revue de sécurité, des invites et des agents réutilisables, des modèles d’évaluation ainsi qu’une responsabilité humaine clairement définie. Sinon, l’IA accroît l’activité sans toujours améliorer la qualité de l’ingénierie ou la valeur métier.
Pourquoi le SDLC doit devenir l’AI-DLC
Les CTO devraient repenser activement le cycle de vie de la livraison logicielle lui-même. Je considère cela comme le passage du SDLC traditionnel à l’AI-DLC, un cycle de vie de livraison augmenté par l’IA pour l’ère de l’IA agentique.
Dans le SDLC traditionnel, nous suivons souvent des phases linéaires : exigences, conception, développement, déploiement et support. Cela fonctionnait relativement bien lorsque l’objectif principal était de créer des logiciels déterministes grâce à des transmissions structurées. Mais avec l’IA, en particulier l’IA agentique, le cycle de vie devient plus itératif et plus condensé.
Je simplifie l’AI-DLC en trois grandes phases : lancement, construction et exploitation.
- Lors du lancement, l’IA aide à la découverte, à la compréhension du code, à l’extraction des règles métier, à l’analyse des dépendances, à la clarification des exigences, à l’identification des risques et à la planification de l’état cible.
- Lors de la construction, l’IA aide à définir les options d’architecture, à décomposer les services, à générer du code et des tests, à produire la documentation, à effectuer les revues de sécurité, à établir les modèles d’infrastructure et à exécuter la modernisation.
- Lors de l’exploitation, l’IA prend en charge l’observabilité, le triage des incidents, les boucles de rétroaction, l’évaluation des modèles, l’optimisation des coûts, la gouvernance et l’amélioration continue.
L’important est que l’AI-DLC ne consiste pas simplement à ajouter un assistant de codage au SDLC. Il s’agit d’un modèle opérationnel d’ingénierie repensé. Il intègre les agents d’IA, la découverte déterministe, la validation humaine, les contrôles de sécurité, la préparation à la production et la gouvernance des coûts au sein d’un même flux de travail.
Comment les équipes d’ingénierie évoluent sous l’effet de l’IA
L’IA a fait évoluer les équipes d’ingénierie d’une exécution séquentielle fondée sur les rôles vers des équipes plus intégrées et axées sur les résultats.
Auparavant, nous nous organisions autour de rôles distincts : architectes, ingénieurs logiciels, ingénieurs des données, équipes DevOps, sécurité, assurance qualité et opérations. Ces rôles restent importants, mais l’IA condense le cycle de vie et réduit la valeur des longues transmissions. Les équipes les plus performantes sont davantage transversales et plus proches du problème métier.
Pour la modernisation guidée par l’IA et l’ingénierie produit, je recherche désormais des équipes qui réunissent plusieurs compétences : de solides bases en ingénierie logicielle, l’ingénierie cloud et plateforme, la maîtrise de l’IA et des données, la sensibilisation à la sécurité, une vision produit et un bon jugement opérationnel. J’accorde également de l’importance aux ingénieurs capables de travailler dans des environnements ambigus, de raisonner à partir des principes fondamentaux et de valider les résultats de l’IA plutôt que de les accepter aveuglément.
Le modèle d’ingénierie déployée au plus près du terrain en est un bon exemple. Au lieu de maintenir l’architecture, l’ingénierie de l’IA, le DevOps et la sécurité dans des filières séquentielles distinctes, nous rapprochons ces compétences de l’environnement du client ou de l’entreprise. L’équipe travaille avec du code réel, des données réelles, des contraintes concrètes et des indicateurs de réussite.
Le recrutement a également évolué. Je reste très attaché à la profondeur technique, mais je recherche aussi des penseurs systémiques : des personnes qui comprennent l’architecture, utilisent l’IA de manière responsable, communiquent avec les parties prenantes métier et assument la responsabilité des résultats en production. À l’ère de l’IA, les meilleurs ingénieurs ne sont pas seulement des producteurs de code. Ce sont des formulateurs de problèmes, des validateurs et des créateurs de systèmes reproductibles.
Comment mesurer l’efficacité de l’IA
Les CTO ne devraient pas mesurer l’IA uniquement au nombre de projets pilotes ou de copilotes déployés, ni à la seule précision des modèles. Ce sont des indicateurs utiles, mais ils ne prouvent pas une transformation…Les CTO doivent convertir l’activité liée à l’IA en capacité reproductible.
Une question que j'aimerais voir posée plus souvent est la suivante : comment les CTO doivent-ils mesurer si l'IA crée une valeur durable pour l'entreprise ?
Les CTO ne devraient pas mesurer l'IA uniquement au nombre de projets pilotes ou de copilotes déployés, ni à la seule précision des modèles. Ce sont des indicateurs utiles, mais ils ne prouvent pas une transformation.
Les CTO devraient mesurer l'IA selon quatre dimensions :
- Productivité de l'ingénierie : l'IA réduit-elle les délais des cycles, améliore-t-elle la qualité du code, augmente-t-elle la couverture des tests, accélère-t-elle la modernisation et réduit-elle la dette technique ?
- Impact sur l'activité : l'IA améliore-t-elle l'expérience client, la productivité des employés, la conversion des revenus, l'efficacité des coûts ou la vitesse de mise sur le marché ?
- Maturité en production : les systèmes d'IA sont-ils sécurisés, observables, fiables, gouvernés et maîtrisés en matière de coûts ? Disposent-ils de responsabilités humaines clairement définies et de critères de validation de l'aptitude à la production ?
- Réutilisabilité et évolutivité : les équipes créent-elles des services d'IA, des agents, des prompts, des modèles, des produits de données et des capacités de plateforme réutilisables, ou produisent-elles des démonstrations isolées ?
C'est important, car l'IA peut générer une grande quantité d'activité visible sans créer de valeur durable. Les CTO doivent convertir l'activité liée à l'IA en capacité reproductible. Cela signifie relier la stratégie, l'architecture, le modèle opérationnel, la gouvernance et les aspects économiques.
Pourquoi les CTO doivent séparer l'expérimentation de l'industrialisation
Voici mes conseils.
Tout d'abord, ne considérez pas l'IA comme une expérimentation secondaire. Considérez-la comme une nouvelle couche opérationnelle de l'entreprise. L'IA influencera la manière dont les logiciels sont développés, dont les employés travaillent, dont les clients interagissent avec l'entreprise et dont les décisions sont prises. Le rôle du CTO est de faire passer l'organisation de projets pilotes dispersés à une stratégie de plateforme d'IA gouvernée et évolutive.
Ensuite, séparez l'expérimentation de l'industrialisation. Il est tout à fait acceptable d'expérimenter rapidement, mais l'IA destinée à la production nécessite une architecture, une sécurité, une gouvernance des données, une évaluation, une observabilité, des contrôles des coûts et une responsabilité humaine clairement définie. De nombreuses entreprises sont bloquées parce qu'elles disposent de nombreuses démonstrations, mais d'aucune voie reproductible vers la production. Les CTO doivent construire cette voie.
Troisièmement, concentrez-vous sur la valeur métier, et non sur la nouveauté des modèles. Les organisations gagnantes ne seront pas celles qui utilisent simplement le modèle le plus récent. Ce seront celles qui intègrent l'IA dans de véritables flux de travail, modernisent leurs fondations technologiques, améliorent la productivité de l'ingénierie et mesurent des résultats tels que le délai de cycle, l'efficacité des coûts, l'expérience client, l'impact sur les revenus et la réduction des risques.
Enfin, mon conseil pratique est de créer conjointement une plateforme d'IA et un modèle d'ingénierie déployée sur le terrain. La plateforme assure la réutilisation, la gouvernance et l'évolutivité. Le modèle FDE introduit l'IA dans des charges de travail réelles de clients et d'entreprises, en utilisant des données réelles, du code réel et des contraintes réelles. C'est ainsi que les CTO peuvent passer de l'ambition en matière d'IA à un retour sur investissement réalisé.
Suivez son actualité
Suivez les travaux de Saurabh Shrivastava sur LinkedIn et consultez sa page d'auteur Amazon.
D'autres entretiens avec des experts seront bientôt disponibles sur The CTO Club !
