Yuri Gubin, CTO chez DataArt – Série d’interviews

Yuri Gubin, CTO chez DataArt est un cadre technologique chevronné et architecte logiciel qui a passé plus de 18 ans chez DataArt, évoluant à travers des postes couvrant l’architecture logicielle, l’architecture de solutions, la technologie cloud, l’innovation et la direction exécutive avant de devenir Chief Technology Officer en mars 2026. Son travail s’est concentré sur la résolution de défis technologiques complexes dans des secteurs tels que les services financiers, la santé, le voyage et l’IoT, avec une expertise particulière en informatique cloud, IA, plateformes de données et architecture logicielle d’entreprise. Avant de devenir CTO, Gubin a occupé pendant plus de cinq ans le poste de Chief Innovation Officer chez DataArt et est membre du Board of Partners de l’entreprise depuis 2021. Il est également membre professionnel du Forbes Technology Council, participant à ses groupes d’experts en IA et en informatique cloud, et agit comme conseiller technologique pour Girls Who Code, où il conseille sur l’architecture, la protection des données, la gouvernance des plateformes et la politique technologique. DataArt le répertorie actuellement comme son Chief Technology Officer basé à New York.

DataArt est une société mondiale d’ingénierie logicielle et de transformation des données et de l’IA, fondée à New York en 1997. L’entreprise compte plus de 6 000 professionnels de la technologie opérant dans plus de 20 pays et travaille avec plus de 400 clients, offrant des services dans des domaines tels que l’intelligence artificielle et l’apprentissage automatique, les données et l’analytique, la transformation cloud, le développement logiciel sur mesure, la cybersécurité et la modernisation des systèmes hérités. DataArt intervient dans des secteurs tels que les services financiers, la santé et les sciences de la vie, le voyage, les médias et le divertissement, ainsi que le commerce de détail, et entretient des partenariats technologiques avec des plateformes dont AWS, Google Cloud, Microsoft Azure, Snowflake et Databricks. En 2025, l’entreprise a annoncé un investissement de $100 million sur trois ans dans ses capacités de données et d’IA, suivi en 2026 du lancement d’Artisyn, un modèle opérationnel activé par l’IA conçu pour intégrer des agents IA, des accélérateurs réutilisables, la gouvernance, la sécurité et la conformité dans le développement de logiciels d’entreprise.

Vous avez passé près de deux décennies chez DataArt, évoluant d’architecte logiciel et d’architecte de solutions à Chief Innovation Officer puis à CTO. Comment ce parcours a-t-il façonné votre manière de distinguer les technologies réellement transformatrices des cycles de battage médiatique, et comment informe-t-il votre « optimisme sceptique » envers l’IA aujourd’hui ?

Nous avons observé de nombreuses vagues au fil des ans, notamment l’essor du cloud et du mobile, différentes générations d’IA, l’automatisation, DevOps et SRE, et j’ai codé, architecturé et conseillé nos clients sur bon nombre de ces sujets pendant toute cette période. Ce que j’ai réalisé, c’est que, oui, on peut faire presque tout avec la technologie, et la technologie est très puissante, mais le diable se cache dans les détails et il faut savoir ce que l’on fait pour que cela ait du sens et fonctionne.

J’ai vu les environnements cloud devenir de plus en plus coûteux, des modèles d’IA qui ne performent pas comme on le pense, et des tentatives mal implémentées d’automatiser les cycles de publication. J’ai constaté l’impact tant des bonnes que des mauvaises décisions, donc chaque fois qu’une nouveauté apparaît et que vous lisez toutes les annonces, promesses et le battage médiatique, je reviens à la même prémisse : presque tout est possible avec la technologie, mais vous avez besoin de savoir ce que vous faites.

On acquiert une bonne maîtrise d’une technologie grâce à la R&D et, surtout, grâce à des projets réels, car c’est ainsi que l’on apprend ce qui est possible, ce qui ne l’est pas, et où les choses peuvent mal tourner. Vous tirez ces leçons de chaque mission, discutez avec vos pairs, d’autres architectes et analystes, et essayez de comprendre s’il existe des schémas et si vous pouvez créer une sorte de système autour d’eux. Finalement, cela devient une orientation, puis vous voyez si les décisions que vous pensiez être bonnes produisent réellement de bons résultats.

C’est de là qu’émane l’optimisme sceptique. Quelles que soient les promesses de la technologie, il faut encore savoir ce que l’on fait, et cette connaissance provient de l’expérience, de la collaboration et d’un effort continu d’apprentissage, d’amélioration et de création d’une sorte de système derrière le battage médiatique.

L’IA d’entreprise semble passer d’une phase d’encouragement à l’expérimentation à une phase de décision sur les expériences qui méritent réellement d’être déployées à grande échelle. Quels signaux vous indiquent qu’un cas d’usage d’IA est prêt pour un déploiement plus large, et quels sont les signes d’avertissement qu’une entreprise se développe trop tôt ?

J’utilise deux méthodes pour comprendre si nous pouvons mettre quelque chose à l’échelle ou si nous devons faire autre chose : la courbe d’adoption et la courbe d’apprentissage.

Pour savoir si un cas d’usage d’IA fonctionne, il faut lui laisser du temps et comprendre la valeur qu’il apporte ainsi que le parcours utilisateur, car ainsi vous pouvez observer les hauts et les bas plutôt que l’effet immédiat « wow » d’une équipe ou d’un flux de travail particulier. Il faut voir ce qui arrive aux mêmes personnes quelques semaines plus tard. Les utilisent‑elles toujours ? Sont‑elles toujours satisfaites de ce cas d’usage, de cette automatisation ou de cette compétence d’IA qu’elles ont créée, ou s’agissait‑il simplement d’un pic qui ne devrait vraiment pas être déployé à grande échelle ?

Certaines de ces choses ne peuvent être validées qu’avec le temps. Il y aura toujours les premiers pionniers, généralement les personnes les plus techniquement compétentes et les plus curieuses, puis il faut l’essayer avec d’autres segments, avec ceux qui suivent les premiers adoptants puis la majorité précoce. Une fois que cela s’est avéré là‑bas, oui, vous pouvez commencer à l’étendre et à développer ce cas d’usage dans d’autres départements.

Chaque sortie majeure de modèle peut créer une pression au sein d’une organisation pour donner immédiatement aux employés accès aux dernières capacités. Comment les dirigeants technologiques doivent‑ils évaluer si un nouveau modèle représente une amélioration significative plutôt que de simplement générer une nouvelle vague d’expérimentation et de coûts ?

Voici à nouveau mon optimisme sceptique. Supposons que vous disposiez déjà d’un modèle et que plusieurs milliers de personnes utilisent l’IA quotidiennement, avec différents modèles et outils déjà disponibles. Lorsqu’un nouveau modèle apparaît, en raison du battage médiatique et de la curiosité naturelle, vous pouvez vous attendre à ce que tout le monde veuille l’expérimenter, ce qui est positif, mais cette expérimentation ne sera pas forcément guidée ou orientée vers des résultats spécifiques, et parfois vous ne pourrez même pas mesurer la différence.

À grande échelle, cela compte. Il ne s’agit pas seulement d’une ou deux personnes qui testent comment le nouveau modèle se comporte par rapport à l’ancien. Cela peut impliquer des milliers de personnes qui passent du temps à expérimenter alors que, pour un cas d’usage particulier, le résultat n’est pas forcément très significatif. En même temps, si quelque chose fonctionne vraiment bien, l’apprentissage de ce qui fonctionne au sein de votre organisation peut ne pas être clairement expliqué ou visible par tout le monde.

C’est pourquoi le premier groupe chargé d’évaluer un nouveau modèle ne doit pas être l’ensemble de l’organisation. Il devrait s’agir d’une équipe R&D travaillant en étroite collaboration avec les équipes concernées, ainsi qu’avec les services juridique et sécurité. Nous évaluons le modèle de manière exhaustive, effectuons une évaluation rapide, puis le présentons à un public plus large avec quelques commentaires et des conseils concernant la sécurité, la conformité et la technologie. Avec l’arrivée constante de nouveaux modèles et de mises à jour majeures, il faut disposer de ce modèle et de cet état d’esprit. Ce n’est vraiment pas un exercice ponctuel ou unique.

DataArt a créé une équipe interfonctionnelle « AI SWAT » regroupant la technologie, le juridique, la conformité, la sécurité de l’information et d’autres équipes. Comment ce groupe fonctionne‑t‑il en pratique, et quels types de risques ou de questions doivent être résolus avant qu’un nouvel outil d’IA ne soit approuvé pour une utilisation plus large ?

Depuis sa création, je pense que nous avons fixé différents objectifs pour ce groupe à peu près tous les quatre ou cinq mois. Nous modifions la priorité, le but et parfois la mission, et bon nombre de ces objectifs portent sur l’IA. Il peut s’agir de former davantage les équipes, de stratégies go‑to‑market et de nouvelles capacités, de partenariats, ou de permettre une adoption plus large de l’IA au sein de l’organisation et à travers le ADLC.

Les sujets exacts évoluent avec le temps, et je pense que c’est sain car il faut constamment revisiter sa propre stratégie, valider ses hypothèses et comprendre s’il faut pivoter et quel sera le prochain thème pour l’équipe.

Le groupe comprend des représentants de différents services, et l’un de ses objectifs est simplement de tenir tout le monde informé. Chaque fois qu’il y a une nouvelle annonce, une question ou une opportunité, quelqu’un peut amener ce sujet à l’une de nos réunions régulières. Même si cela ressemble à une question technologique pertinente uniquement pour une petite équipe, ces sujets peuvent aujourd’hui avoir des répercussions sur de nombreuses parties de l’organisation.

C’est pourquoi, lorsque nous évaluons un nouveau partenariat, outil ou accélérateur, nous en discutons ouvertement afin que chacun comprenne la direction prise et ait la possibilité de poser des questions ou d’assurer une supervision. Pour un nouvel outil d’IA, la technologie ne peut pas l’évaluer isolément. La sécurité, le juridique et la conformité doivent également comprendre comment il traite les données de l’entreprise ou des clients, quelles contraintes s’appliquent et s’il peut être utilisé en toute sécurité à grande échelle.

Parfois, l’équipe AI SWAT travaille également sur des programmes spécifiques, comme la montée en compétences, où nous fixons des objectifs, élaborons des feuilles de route et décidons comment les différents groupes seront intégrés. C’est réellement ainsi que cela fonctionne : tenir les personnes informées, collaborer sur des programmes précis et offrir une visibilité au comité d’administration sur ce qui se passe avec l’IA dans l’ensemble de l’entreprise.

Vous observez des attitudes très différentes vis‑à‑vis du développement logiciel assisté par l’IA, certaines organisations développant activement le développement agentique tandis que d’autres interdisent encore le code généré par l’IA. Qu’est‑ce qui explique cette fracture, et que faut‑il changer avant que les entreprises soucieuses du risque ne se sentent à l’aise avec un rôle plus important de l’IA dans l’ingénierie logicielle ?

Probablement, ce qui explique la différence entre ceux qui disent non et ceux qui disent oui, c’est leur appétit pour le risque et leur attitude face à l’ambiguïté et à l’incertitude. Ce qui aide les deux types d’organisations, c’est l’éducation continue, l’expérimentation et l’évaluation. Même parmi les nombreuses organisations avec lesquelles nous travaillons et qui adoptent l’IA partout, il existe encore des défis liés à la mesure des résultats et de l’impact. Pour être honnête, la question de la façon dont on mesure l’impact de l’IA et comment on évalue la performance d’une équipe surgit parfois de nulle part, comme si personne n’y avait réellement pensé auparavant.

Une fois que vous commencez à évaluer une initiative d’IA de manière plus exhaustive, vous commencez à comprendre l’impact et la valeur qu’elle vous apporte réellement, ce qui conduit à de meilleures décisions quant à l’endroit où la technologie a du sens. Pour les entreprises qui disent non à l’IA, il faut néanmoins mettre en place un processus continu d’examen de ce que la technologie peut faire et de son état actuel. Vous ne voulez pas qu’une décision prise il y a trois ans reste une politique d’entreprise simplement parce que personne n’a revu les hypothèses sous-jacentes.

L’IA agentique facilite de plus en plus la création d’agents propres par les équipes individuelles, ce qui peut entraîner la multiplication d’agents exécutant des tâches presque identiques. À quel moment l’expérimentation devient-elle une prolifération d’agents, et quel type de couche de gouvernance est nécessaire pour gérer la propriété, les autorisations, les duplications et la gestion du cycle de vie ?

Lorsque nous observons un scénario typique où une licence d’IA est attribuée à chaque développeur et que l’expérimentation devient non guidée, tout le monde commence à créer ses propres solutions et à travailler à sa manière. En général, cela conduit à des équipes sous‑performantes, à des attentes non satisfaites, à une qualité en retard et à une hausse des dépenses. En fin de compte, cela ne fait pas ce que tout le monde attend, la qualité est mauvaise et cela devient coûteux. Pour atténuer cela, il faut que ce soit un effort d’équipe intégré à un département ou à une initiative organisationnelle plus large, et c’est là que la gouvernance intervient.

Au niveau du projet, vous pouvez vous mettre d’accord sur la base de connaissances et le contexte, ainsi que sur les cas d’usage où vous commencez à utiliser l’IA. Vous créez ensuite des compétences et des agents qui font partie du flux de travail de développement et que tout le monde peut réutiliser, ce qui vous permet d’accumuler connaissances et bonnes pratiques plutôt que de les recréer à chaque fois. Cet effort au niveau du projet devrait ensuite être orchestré par un comité d’architecture d’entreprise, un groupe technologique, le CTO ou une équipe responsable de l’adoption de l’IA. Vous voulez réutiliser les agents qui fonctionnent bien, vous assurer que le processus est solide et que cela fonctionne à l’échelle de l’organisation plutôt que de sombrer dans le chaos et le bruit.

Je pense donc qu’il doit s’agir d’un effort synchronisé au niveau du projet, voire du programme, puis également aux niveaux du département et de l’organisation.

La consommation de tokens et les coûts d’inférence peuvent sembler relativement faibles lors d’un pilote, mais devenir significatifs lorsque les systèmes d’IA sont déployés auprès de milliers d’employés ou d’agents autonomes. Comment les entreprises doivent‑elles envisager la gestion des coûts d’IA, et prévoyez‑vous l’émergence d’une discipline semblable à FinOps spécifiquement pour les charges de travail d’IA ?

Je commencerai par dire qu’un scénario presque idéal est celui où les coûts d’IA augmentent, atteignent un plateau, puis commencent à diminuer légèrement avec le temps. Cela indique que vous pouvez prévoir, contrôler les coûts, comprendre ce que vous dépensez réellement en IA et voir les résultats des décisions que vous prenez. Les mauvaises situations surviennent lorsque les coûts continuent de fluctuer, car cela signifie généralement que quelque chose n’est pas durable, ou lorsque les coûts augmentent puis tombent complètement parce que l’adoption ne se produit pas, que quelque chose ne fonctionne pas, ou que les gens utilisent autre chose et que vous ne le voyez tout simplement pas.

Donc FinOps existe, et AI FinOps existe également. Certaines techniques sont très techniques, tandis que d’autres sont assez simples. Cela peut être aussi basique que de choisir le modèle préféré afin de ne pas toujours dépendre du plus coûteux, et décision par décision ces choix commencent à économiser de l’argent. En même temps, savoir économiser et contrôler les coûts n’est que la moitié de l’équation. FinOps, à mon sens, est une discipline et une méthodologie qui implique également les responsables produit et business, car il faut définir ce que vous mesurez lors de l’évaluation des efforts d’IA.

Donc oui, je pense que l’AI FinOps est un bon sujet pour l’équivalent d’une équipe SWAT IA à discuter : combien vous dépensez, ce que vous récupérez, comment vous le contrôlez et où se trouvent les opportunités.

De nombreuses entreprises se voient demander de démontrer le ROI de l’IA alors même qu’elles n’ont jamais établi de référence fiable sur la productivité de leurs équipes avant l’introduction de l’IA. Que devraient réellement mesurer les organisations si elles veulent déterminer si l’IA crée une valeur commerciale significative ?

Quel que soit votre attitude envers l’IA ou votre situation actuelle, vous utilisez peut‑être déjà des agents à tout va ou vous pensez que l’année prochaine vous commencerez à utiliser l’IA ; établir une référence est aujourd’hui absolument indispensable.

Il existe plusieurs catégories de métriques. Certaines sont subjectives, et cela peut simplement être le retour d’information de vos développeurs ou employés, car vous travaillez avec des personnes et il est important de comprendre comment elles perçoivent la valeur de l’IA. Des mesures plus objectives peuvent commencer par des métriques mécaniques ou synthétiques, bien que je conseille à tous de ne pas s’y attacher trop étroitement. Je parle de choses comme les commits de code ou les story points. Ces métriques montrent que du travail a eu lieu, mais elles ne montrent pas réellement la valeur ou l’impact.

Ce qui compte le plus, ce sont les métriques qui expliquent à quelle vitesse ou avec quelle qualité le travail a été livré. Pensez aux métriques DORA telles que le délai de livraison ou le MTTR, à la rapidité avec laquelle vous pouvez récupérer d’une défaillance, à la rapidité avec laquelle vous pouvez corriger un bug en production, ou à la façon dont ces mesures évoluent dans le temps. Un chiffre à un moment donné ne vous indique pas la trajectoire. L’un de nos architectes a récemment mentionné qu’en développement logiciel, une bonne métrique pourrait également être la fiabilité des estimations à mesure que l’adoption de l’IA augmente, car cela indique quelque chose sur la durabilité de ces efforts et sur la productivité réelle des équipes. Vous devez également suivre les coûts, car si vous ne parlez que des avantages sans comprendre ce que cela coûte à réaliser, vous n’avez pas une vision complète.

Hors du développement logiciel, j’y réfléchis de manière similaire. Dans chaque flux de travail ou processus, il existe une unité de travail et une définition du « done ». Que vous traitiez des réclamations, examiniez des documents ou gériez des demandes de clients, définissez ce que vous livrez puis mesurez le temps que cela prenait avant l’IA, la rapidité et la qualité avec lesquelles vous pouvez le faire maintenant, ainsi que le coût. Cela vous fournit un bon point de départ à la fois pour la ligne de base et pour le cadre des métriques.

DataArt a intégré l’IA tout au long du cycle de vie de la livraison logicielle grâce à des initiatives telles qu’Artisyn. À mesure que l’IA prend en charge davantage de tâches d’implémentation, de test et de flux de travail, quelles parties de l’ingénierie logicielle deviennent plus précieuses pour les humains, et quelles compétences risquent de devenir moins importantes ?

Vous ne pouvez utiliser l’IA efficacement en développement que si vous vous souvenez encore de la définition de bon. Vous avez besoin de cette expertise pour guider vos agents, examiner le résultat, définir des contraintes et établir les règles. Vous devez comprendre ce qu’est la meilleure pratique et à quoi doit ressembler une architecture solide, car sans cela, vous pourriez ne pas savoir ce qui est développé, et la valeur de ce type d’expertise augmente de façon très, très significative.

Comprendre les modèles architecturaux est important, tout comme comprendre ce qui est approprié dans une certaine industrie, application ou catégorie de solution. Vous devez savoir quel type d’architecture est adéquat aujourd’hui et quel type le restera lorsque la solution évoluera, car parfois la même architecture ne fonctionne pas pendant toute la durée de vie d’une solution ou d’une plateforme.

Cet équilibre entre ce qui est approprié pour une solution particulière constitue l’aspect humain. C’est le goût, le savoir-faire derrière les services et le développement logiciel. Vous devez savoir ce que vous faites, et cela provient également de la compréhension du client et du secteur.

Quelles compétences sont moins importantes ? Il m’est vraiment difficile de répondre, bien que peut‑être la rapidité avec laquelle vous pouvez taper du code. Je plaisante, mais le code peut désormais être créé beaucoup, beaucoup plus rapidement, et la connaissance spécifique d’une bibliothèque ou d’un langage particulier peut également être apprise beaucoup plus vite avec l’IA.

J’ai vu des développeurs .NET se reconvertir en développeurs Java très rapidement, et il y a cinq ou dix ans, j’aurais dit que le faire à grande échelle était presque impossible. De nos jours, c’est possible. Un développeur senior expérimenté peut de plus en plus passer d’un langage à l’autre, car ce qui compte réellement, c’est sa compréhension de la technologie, de l’architecture, des meilleures pratiques de solution, du SDLC et de l’ADLC.

À mesure que les entreprises passent de dizaines de projets pilotes d’IA à des systèmes de production capables d’agir de façon autonome, où la responsabilité doit-elle finalement reposer lorsqu’un agent IA commet une erreur coûteuse : auprès du développeur, du propriétaire de l’entreprise, du fournisseur du modèle, de l’équipe de gouvernance, ou d’une combinaison de ceux‑ci ?

J’aime l’idée d’une collaboration sans blâme et d’une responsabilité partagée, car chaque personne de l’organisation contribue aux meilleures pratiques, aux cadres architecturaux et aux solutions. Même si un développeur crée du code avec ou sans IA, un autre développeur le révise, les chefs d’équipe donnent des orientations, les architectes fournissent l’architecture et les contraintes, et l’équipe de gouvernance participe aux décisions concernant les budgets, le calendrier et le déploiement. Tout le monde est impliqué d’une manière ou d’une autre.

Très souvent, lorsqu’un problème survient, c’est le processus qui ne fonctionne pas, de sorte que, en ce sens, la responsabilité est partagée entre différents rôles. Mais dire simplement que la responsabilité est partagée et donc sans blâme n’est pas suffisant. Elle doit encore être décomposée en responsabilités spécifiques.

Les développeurs sont responsables du code qu’ils soumettent sous forme de pull request, et ils doivent comprendre ce qui s’y passe. Les architectes sont responsables des décisions qu’ils prennent et des décisions architecturales fournies aux agents et aux développeurs. L’équipe plateforme est responsable de la fiabilité de la solution, quel que soit l’auteur ou la source de la ligne de code concernée.

La responsabilité existe donc, mais vous devez la définir de manière granulaire par équipe, rôle et département. Ce que vous ne pouvez pas faire, c’est arrêter l’analyse à « l’IA a fait cela ». Vous devez vous demander quels contrôles, tests ou surveillances ont permis à cet échec d’atteindre la production.

Si l’absence de tests unitaires a permis à du code défectueux d’être déployé en production, ou si le manque de supervision et de révision l’a rendu possible, vous ne pouvez pas reporter cette responsabilité à l’IA. Vous ne pouvez pas non plus simplement blâmer le fournisseur du modèle ou le fournisseur cloud pour chaque bug ou interruption.

Merci pour cette excellente interview, les lecteurs qui souhaitent en savoir plus devraient visiter DataArt.