La gouvernance de l’IA ne peut pas être une réflexion après coup

Abhishek Ranjan est le directeur technique d’Apna et de Blue Machines, où il joue un rôle central dans la transformation des effectifs humains et de ceux constitués par l’IA.

Nous nous sommes entretenus avec lui pour discuter de la gouvernance des flux de travail liés à l’IA. Voici ce qu’il nous a dit.

La technologie aux côtés des humains

Je m’appelle Abhishek Ranjan. Je suis le directeur technique d’Apna et de Blue Machines. Deux univers très liés, mais différents, ont façonné mon parcours jusqu’à ce moment de transformation par l’IA.

Chez Apna, nous concevons des solutions pour la main-d’œuvre humaine. Apna est l’une des licornes indiennes à la croissance la plus rapide, avec plus de 60 millions d’utilisateurs sur la plateforme. À cette échelle, nous observons de très près la main-d’œuvre indienne. Nous voyons des millions de personnes à la recherche de meilleures opportunités, des employeurs qui essaient de recruter plus rapidement, ainsi que des langues, des niveaux de compétence et des niveaux d’accès et de confiance numériques différents.

Chez Blue Machines, nous concevons des solutions pour la main-d’œuvre de l’IA. Nous nous concentrons sur l’IA vocale d’entreprise, en traitant des millions de minutes chaque jour. Nous ne créons pas seulement des robots qui répondent aux questions. Nous créons des travailleurs fondés sur l’IA capables de dialoguer avec les clients, de comprendre le contexte, de recueillir des commentaires, de s’améliorer au fil du temps et d’exécuter de véritables flux de travail métier.

J’ai vu la technologie aider les humains à trouver un emploi, à progresser et à participer à l’économie. Et maintenant, je vois l’IA elle-même devenir une nouvelle forme de main-d’œuvre capable de travailler aux côtés des humains.

Pour moi, ce moment ne consiste donc pas seulement à utiliser l’IA pour gagner en productivité ou à écrire du code plus rapidement. Il s’agit de repenser la manière dont les entreprises fonctionnent et dont le travail lui-même est réalisé.

L’architecture de deux entreprises très différentes

L’architecture d’Apna est conçue comme celle d’une vaste plateforme de marché. Nous disposons de systèmes destinés aux consommateurs et aux employeurs, de plateformes de données, de systèmes d’IA et de mise en relation, de recherche, de communication, de couches de lutte contre la fraude et de confiance, ainsi que, désormais, de fonctionnalités de recrutement et de préparation aux entretiens fondées sur l’IA. Le modèle de déploiement privilégie le cloud, est hautement évolutif et conçu pour assurer une haute disponibilité, car des millions d’utilisateurs et des milliers d’entreprises utilisent la plateforme.

L’organisation d’ingénierie compte plus de 100 personnes, réparties entre les équipes d’ingénierie produit, backend, frontend, mobile, données, IA, infrastructure, sécurité et plateforme. Nous nous concentrons non seulement sur la création de fonctionnalités, mais aussi sur la conception de systèmes fiables capables de fonctionner à très grande échelle.

Blue Machines est une organisation technologique d’un autre type. Elle se concentre sur l’IA vocale d’entreprise et les flux de travail agentiques. Nous créons des travailleurs fondés sur l’IA capables de dialoguer, de raisonner, d’agir, de s’intégrer aux systèmes métier et de s’améliorer grâce aux retours. Aujourd’hui, nous opérons déjà à une échelle importante, avec des millions de minutes d’IA vocale traitées chaque jour.

L’architecture de Blue Machines est davantage en temps réel et native de l’IA. Elle comprend l’infrastructure vocale, la téléphonie, la conversion de la parole en texte, le raisonnement des LLM, la synthèse vocale, l’orchestration des flux de travail, les intégrations, l’analyse, l’observabilité et les systèmes d’évaluation. La complexité produit est élevée, car l’IA vocale d’entreprise doit fonctionner en production, dans de véritables conversations, avec une faible latence, une grande précision, des mécanismes de protection de la conformité et des résultats métier clairement définis.

Chez Blue Machines, une équipe centrale de quatre ingénieurs a créé une plateforme distribuée d’orchestration vocale en l’espace de quelques semaines. Nous disposons également d’une équipe de recherche très expérimentée qui travaille en profondeur sur l’IA vocale, l’évaluation des agents, le raisonnement, la latence, les systèmes multilingues et l’amélioration des agents au fil du temps. Cette profondeur de recherche est importante, car l’IA vocale d’entreprise ne peut pas être résolue uniquement en assemblant des modèles. Elle exige une solide ingénierie produit, une solide ingénierie des systèmes et une solide recherche appliquée en IA.

Dans l’ensemble, l’organisation technologique que je dirige se situe à l’intersection des plateformes à grande échelle et des systèmes natifs de l’IA.

Comment une IA bien gouvernée améliore le cycle de vie des logiciels

Au cours de l’année écoulée, l’IA a changé la manière dont nous concevons, testons et mettons en production les technologies.

Auparavant, notre processus de mise en production était plus traditionnel. Les ingénieurs développaient les fonctionnalités, créaient des demandes de fusion, passaient par des évaluations entre pairs, exécutaient les cas de test, puis les déployaient via le pipeline de déploiement habituel. Cela fonctionnait, mais la vélocité dépendait des cycles d’évaluation humaine, de l’assurance qualité manuelle et de la confiance de l’équipe dans la mise en production.

À mesure que le développement assisté par l’IA prenait une place plus importante dans l’ingénierie, nous l’avons adopté — et nous avons rapidement compris que les gains de vitesse à eux seuls ne suffisaient pas. L’IA peut aider les ingénieurs à écrire du code plus rapidement, mais si la gouvernance ne s’améliore pas, elle peut également générer davantage de bogues cachés, de cas limites non pris en compte ou d’abstractions de mauvaise qualité.

Nous avons donc modifié le modèle opérationnel.

1. Nous avons ajouté une couche d’évaluation des demandes de fusion assistée par l’IA. Chaque demande de fusion faisait l’objet de contrôles portant sur la logique à risque, les cas limites manquants, les ruptures de contrat d’API, les problèmes de sécurité, les risques liés aux migrations et la faiblesse de la couverture des tests, avant l’évaluation humaine. Cela a permis de réduire les oublis évidents avant l’évaluation.
2. Nous avons renforcé les contrôles d’intégration continue. Une modification ne pouvait pas être acceptée uniquement parce que le code semblait correct. Elle devait réussir les tests unitaires, les tests d’intégration, la vérification du style de code, les contrôles de sécurité, les tests de contrat d’API et les suites de régression pour la partie du produit concernée.
3. Nous avons constitué des ensembles de régression plus robustes pour les flux de travail critiques. Par exemple, en ajoutant des cas de test couvrant des scénarios utilisateur réels, les cas limites, le comportement multilingue, la gestion des échecs et les résultats métier.
4. Nous avons modifié la gouvernance des invites. Nous y reviendrons dans un instant.
5. Nous avons rendu les déploiements canari obligatoires pour les domaines à haut risque. Au lieu de déployer la version pour tout le monde, nous la déployons auprès d’un faible pourcentage du trafic, surveillons les erreurs, la latence, la conversion, les abandons, la qualité de l’agent et l’impact sur les clients, puis nous la généralisons ou revenons en arrière.
6. Nous avons amélioré l’observabilité. Lorsqu’un problème survenait, nous voulions savoir exactement quelle version du code, quelle version de l’invite, quel modèle, quel flux de travail ou quelle dépendance en était à l’origine.

L’impact est très visible. Notre vélocité de mise en production a considérablement augmenté. Les équipes qui livraient auparavant des versions plus importantes et regroupées passent désormais à des mises en production plus petites et plus fréquentes. Dans certains domaines, la fréquence des mises en production a presque été multipliée par 2 ou 3, car les contrôles sont davantage automatisés et la confiance est plus grande. C’est ainsi qu’une équipe de quatre personnes a construit une plateforme distribuée complexe en quelques semaines.

Le nombre de problèmes en production a également diminué, car chaque mise en production est plus petite, mieux testée et plus facile à annuler. Nous constatons une baisse significative des bogues en production, en particulier là où la régression automatisée et les déploiements canari sont désormais obligatoires. Aujourd’hui, le nombre de défauts est inférieur de près de 40 % à la référence initiale.

L’IA seule apporte de la vitesse. L’IA associée à la gouvernance apporte vitesse et qualité.

Pourquoi les invites doivent être traitées comme du code

Abhishek partage

Pour les systèmes d’IA, nous avons également commencé à traiter les invites comme du code… Cela a constitué une amélioration importante. Nous savons quelle invite était active, ce qui a changé, ce qui s’est amélioré et si les résultats pour les clients se sont améliorés.

Pour les systèmes d’IA, nous avons également commencé à traiter les invites comme du code.

Nous versionnons, évaluons et testons désormais les invites, les promouvons entre les environnements et les déployons progressivement. Les invites ne sont plus considérées comme de petites mises à jour de configuration. Elles font l’objet de conversations de test, de vérifications des cas limites, de contrôles multilingues, de contrôles de latence, de contrôles de conformité et de vérifications des résultats métier.

Nous pouvons d’abord déployer une nouvelle invite ou un nouveau flux de travail d’agent auprès d’un faible pourcentage du trafic, observer les résultats, puis la ou le généraliser si les indicateurs sont meilleurs.

Cela a constitué une amélioration importante. Auparavant, il était difficile de savoir si une modification d’invite améliorait l’agent ou ne faisait que modifier son comportement. Désormais, nous pouvons comparer les versions de manière plus objective. Nous savons quelle invite était active, ce qui a changé, ce qui s’est amélioré et si les résultats pour les clients se sont améliorés.

Le changement le plus important est que l’ensemble du système technologique est devenu plus automatisé, plus mesurable et mieux gouverné.

Un flux de mise en production d’ingénierie agentique

Nous utilisons un flux de mise en production d’ingénierie agentique, avec l’intervention d’humains à des étapes clés.

Ce flux ne convient pas à toutes les mises en production. Pour les modifications très complexes de la plateforme, les changements architecturaux en profondeur ou les systèmes sensibles, nous utilisons encore un processus plus traditionnel, dirigé par des humains. Mais pour certains domaines du produit, notamment les flux de travail qui évoluent plus rapidement, il est devenu la méthode de développement par défaut.

Voici le flux de travail :

1. Le processus commence lorsqu’une exigence produit ou un problème d’ingénierie est identifié. Un agent de planification IA lit l’exigence, la décompose en tâches, identifie les dépendances, signale les zones à risque et propose un plan de mise en œuvre. L’ingénieur examine le plan, corrige les hypothèses et décide de l’approche finale.
2. Ensuite, un agent de programmation génère du code, refactorise les modules, rédige le code répétitif et crée des tests unitaires et d’intégration. Un agent de revue vérifie la demande de fusion afin de détecter les logiques à risque, les cas limites manquants, les problèmes de sécurité, les ruptures de contrats d’API et les lacunes de test.
3. Puis, un agent de test crée des scénarios de régression et valide les cas limites. Pour les flux de travail IA, il exécute également des évaluations d’invites, des tests de conversation, des vérifications multilingues, des contrôles de latence et des vérifications des résultats métier.
4. L’agent de mise en production recommande ensuite si la modification peut être déployée sans risque auprès d’un sous-ensemble d’utilisateurs, en fonction des résultats des tests, de la zone d’impact, des échecs passés et de la préparation à l’observabilité. Toutefois, les humains approuvent toujours les mises en production critiques, en particulier si la modification affecte les revenus, l’expérience client, la sécurité ou l’infrastructure centrale.
5. Une fois la modification publiée, l’agent de supervision surveille les erreurs, la latence, les conversions, les abandons, la qualité de l’agent et l’impact client. Si quelque chose semble incorrect, il recommande une restauration, ouvre un incident, résume les journaux et crée une première ébauche d’analyse des causes profondes.

Ce flux de travail est agentique, mais pas aveuglément autonome. Les agents IA planifient, programment, examinent, testent, publient, surveillent et résument. Les humains approuvent, remettent en question, établissent les priorités et prennent la décision finale.

Les domaines où Claude Code et Cursor excellent

Mes outils préférés sont Claude Code et Cursor, selon le flux de travail.

Cursor excelle lorsque les ingénieurs souhaitent intégrer profondément l’IA à leur environnement de développement intégré pour la programmation quotidienne, la refactorisation, la compréhension de la base de code et une mise en œuvre plus rapide.

Claude Code se révèle extrêmement utile pour les tâches plus agentiques : comprendre de grandes bases de code, effectuer des modifications sur plusieurs fichiers, générer des tests, corriger des problèmes et itérer comme un partenaire d’ingénierie.

Pourquoi l’IA apporte un effet de levier tandis que les humains exercent leur jugement

Nous dépendons désormais fortement de l’IA pour tout ce qui améliore la rapidité, la couverture ou la cohérence, mais pas pour les tâches nécessitant du jugement, de la responsabilité ou des compromis à long terme.

Par exemple, l’IA nous aide désormais pour la revue de code, la génération de cas de test, la couverture de régression, la documentation, le débogage, l’analyse des journaux et même le triage des incidents. Elle peut rapidement identifier les chemins de code à risque, les cas limites manquants, les problèmes de sécurité potentiels ou les tendances dans les défaillances en production. Dans les systèmes d’IA, elle nous aide également à comparer les versions d’invites, à évaluer les conversations et à comprendre où un agent échoue.

Mais les décisions finales restent humaines. Voici quelques exemples :

• Les choix d’architecture doivent rester humains, car ils impliquent des compromis liés à la capacité de montée en charge, aux coûts, à la fiabilité, aux compétences de l’équipe et à l’orientation à long terme du produit.
• L’analyse des causes profondes de bout en bout peut être assistée par l’IA, mais les humains doivent toujours relier les éléments entre eux, valider l’hypothèse et décider de la correction.
• La priorisation du carnet de tâches reste humaine, car elle nécessite de comprendre les clients, la stratégie de l’entreprise et de juger ce qui compte réellement.
• Les revues de sécurité utilisent l’IA, mais le jugement d’experts reste nécessaire. L’IA peut signaler des problèmes, mais elle peut aussi générer des faux positifs ou ne pas détecter des risques liés au contexte métier. Les humains conservent la responsabilité, car les risques et le niveau de responsabilité sont trop élevés.

Exemples concrets d’échecs de l’IA dans le jugement technique

Voici quelques exemples de l’importance du jugement humain.

Le premier concernait des pics de latence de l’ordre de la milliseconde dans notre pipeline vocal. L’IA a correctement commenté le problème et identifié que la latence sur un chemin pouvait devenir problématique. Mais le code qu’elle a suggéré était incorrect. Il semblait propre, mais il aurait créé un autre goulot d’étranglement sous charge. Un ingénieur humain est intervenu, a compris le comportement à l’exécution et a corrigé le problème correctement.

Un autre exemple est survenu lors de l’analyse d’un problème en production. Plusieurs systèmes en aval étaient défaillants, et l’IA continuait à analyser ces systèmes indépendamment en suggérant des optimisations. Mais nous savions déjà que le véritable problème était une dépendance en amont qui avait échoué en premier. L’IA confondait les défaillances visibles avec la cause racine.

C’est là que l’IA rencontre encore des difficultés. Elle peut lire les journaux, résumer les traces, suggérer des corrections et accélérer le débogage. Mais dans les systèmes distribués complexes, elle peut ne pas saisir la causalité, le facteur temps et le contexte global du système.

Pourquoi les équipes deviennent plus réduites tout en gagnant en polyvalence

L’IA a davantage modifié le profil des personnes recrutées que l’organigramme.

Auparavant, nous recrutions selon une expertise fonctionnelle plus spécialisée : backend, frontend, assurance qualité, DevOps, données, etc. Ces compétences restent importantes, mais je privilégie désormais les ingénieurs capables d’intervenir sur l’ensemble de la pile technique, d’utiliser l’IA en profondeur et de passer du problème à la mise en production avec beaucoup moins d’accompagnement.

Les meilleurs ingénieurs ne se contentent plus d’écrire du code. Ils conçoivent des flux de travail, utilisent l’IA pour l’implémentation, génèrent des tests, examinent les résultats, déboguent plus rapidement et réfléchissent à la qualité des mises en production.

Le niveau d’exigence du recrutement s’est donc déplacé vers des ingénieurs faisant preuve d’un fort sens des responsabilités et d’un grand discernement. Des personnes capables de poser les bonnes questions, de vérifier les résultats de l’IA, de comprendre les systèmes en profondeur et de livrer de manière autonome.

Cela a également réduit le besoin de grandes équipes dans certains domaines. Une équipe plus réduite, tirant pleinement parti de l’IA, peut désormais accomplir un travail qui nécessitait auparavant beaucoup plus de personnes.

Pourquoi l’IA rend plus difficile la formation des ingénieurs débutants

Abhishek partage

Je ne pense pas qu’interdire l’IA ou obliger les gens à coder comme en 2010 soit la solution. Ce serait une erreur. Mais je ne pense pas non plus que nous ayons totalement résolu la manière de développer un jugement technique approfondi lorsque l’IA accomplit une si grande partie du travail préliminaire. Pour l’instant, ma meilleure réponse consiste à rendre la compréhension visible.

Comment former les ingénieurs débutants à l’ère de l’IA ? Je n’ai pas encore de réponse parfaite.

Lorsque nous avons commencé, les environnements de développement intégrés nous ont aidés. Ensuite, Google nous a aidés. Puis Stack Overflow nous a aidés. Mais durant toutes ces phases, il fallait encore se confronter au problème. Il fallait comprendre la réponse, l’adapter, la déboguer et apprendre pourquoi elle fonctionnait.

Avec l’IA et le codage intuitif, nous pouvons éviter cette difficulté. Un ingénieur débutant peut générer du code fonctionnel sans vraiment comprendre le système, les compromis ou les modes de défaillance. Cela m’inquiète.

Je ne pense pas qu’interdire l’IA ou obliger les gens à coder comme en 2010 soit la solution. Ce serait une erreur. Mais je ne pense pas non plus que nous ayons totalement résolu la manière de développer un jugement technique approfondi lorsque l’IA accomplit une si grande partie du travail préliminaire.

Pour l’instant, ma meilleure réponse consiste à rendre la compréhension visible. Les ingénieurs doivent être capables d’expliquer pourquoi le code fonctionne, où il peut échouer, quels tests sont importants, ce qui se passe à grande échelle et comment ils le débogueraient en production.

Comment gérer l’utilisation des jetons

Le coût a également constitué un défi lié à l’IA.

L’utilisation des jetons semble inoffensive au début, mais dès que l’IA intervient dans le codage, les revues, les tests, le débogage et les flux de travail agentiques, les coûts peuvent augmenter très rapidement.

Nous devons donc désormais mesurer le retour sur investissement par flux de travail et utiliser une orchestration plus intelligente. Toutes les tâches ne nécessitent pas le modèle le plus coûteux.

L’avenir consiste à utiliser le bon modèle pour la bonne tâche.

Pourquoi les CTO doivent avancer rapidement — avec des contrôles

Voici mon conseil : construisez rapidement. Expérimentez rapidement. Intégrez l’IA aux flux de travail réels de l’ingénierie, des produits, du support, des ventes, des opérations et des équipes internes. Ne prétendez pas qu’elle ne fonctionne pas. Elle fonctionne, parfois de manière étonnamment efficace.

Mais ne devenez pas des croyants aveugles. L’IA est puissante, mais ce n’est pas de la magie. Vous avez besoin de contrôle, de gouvernance, de tests, d’observabilité et d’une responsabilité clairement définie. Sinon, vous ne ferez que créer un chaos plus rapide.

Le bon état d’esprit n’est ni « l’IA va tout remplacer » ni « l’IA est surestimée ». Le bon état d’esprit est : « comment puis-je utiliser cet outil pour rendre mon organisation dix fois plus performante ? »

Suivez la suite

Suivez Abhishek Ranjan sur LinkedIn. Et découvrez sa newsletter Hacktivate.

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