Du « Shadow AI » à l’adoption

Du « Shadow AI » à l’adoption

Disclaimer : Cet article est un retour d’expérience de nos clients chez Arolla. Ce n’est peut être pas représentatif de tout le marché.

Aujourd’hui, l’Intelligence Artificielle est là et dans la plupart des équipes de développement,
elle s’est installée naturellement, souvent de manière cachée appelée communément “Shadow AI”, par des devs qui l’utilisent à titre personnel pour gagner en efficacité. D’un autre côté, on retrouve les réfractaires, les devs qui ne veulent pas utiliser l’IA pour plusieurs raisons : écologique, éthique ou par peur de voir leur métier disparaître.

Face à cela, les managers se retrouvent à la croisée des chemins. Comment transformer une pratique individuelle et hétérogène en un levier de performance collective, sans braquer des expertes et des experts attachés à leur savoir-faire artisanal ?

Le dilemme du management : Quotas vs Culture

En accompagnant nos clients, nous avons vu deux visions qui s’affrontent dans les organisations. Il y a des avantages et des inconvénients à chacune, tout dépendra du contexte comme on dit.

D’un côté, on trouve le pilotage par la contrainte. Pour forcer l’adoption, certains font le choix de la métrique. Chez une grande entreprise, par exemple, des seuils de 40 prompts minimum par semaine ont été évoqués pour inciter à l’utilisation de l’outil à marche forcée. Le risque est donc de transformer l’IA en une corvée administrative où les dévs hackeraient le système pour atteindre le quota, au détriment de la qualité réelle. En face de cette métrique, l’organisation vérifie le taux d’adoption et d’acceptation des propositions de l’IA. Plus on accepte et plus, le résultat est pertinent. et là encore il y a le risque d’accepter les suggestions et puis supprimer à la main les modifications apportées. Je vous laisse imaginer la suite du scénario.

De l’autre côté, l’accompagnement par la valeur : Dans d’autres organisations, à l’inverse, l’enjeu est de faire comprendre que l’IA ne remplace pas les devs, mais le transforme en intrapreneur capable d’automatiser le déterministe pour se concentrer sur l’architecture et la valeur métier. Et le risque de cette pratique est de voir fleurir des produits innovants certes mais qui ne sont pas alignés avec la vision de l’organisation.

Un parcours de changement en trois étapes

Pour réussir ce passage à l’échelle, chez Arolla, nous proposons une approche méthodique. L’objectif n’est pas seulement de distribuer des licences, mais d’harmoniser les pratiques pour éviter que l’IA ne devienne une source de bugs incontrôlés en production. Le parcours que nous proposons se décline ainsi :

1. L’État des lieux via le Craft Radar : On ne peut pas transformer ce qu’on ne mesure pas. Il s’agit d’évaluer la maturité technique et l’alignement stratégique des équipes avant d’introduire les pratiques et les outils.

2. La formation Context Engineering : Dépasser le simple « prompt » pour apprendre à concevoir des interactions fiables, économes et modulaires avec les modèles.

3. Le Coaching de terrain : Ancrer les pratiques dans le quotidien par l’immersion et la création d’ambassadeurs internes avec une Guilde IA par exemple, garante de l’amélioration continue et de la diffusion des savoirs.

Le but final n’est pas de transformer les développeurs en presse-boutons, mais en intrapreneurs capables d’automatiser les tâches déterministes pour se concentrer sur la valeur ajoutée. L’excellence logicielle ne se mesure pas au nombre de clics sur « Accepter », mais à la capacité de l’équipe à rester maîtresse de son code.

Mesurer le succès au-delà du simple « nombre de prompts »

Pour piloter efficacement l’adoption de l’IA, il est crucial de ne pas se limiter à des métriques de volume, comme le nombre de messages envoyés ou le taux d’acceptation du code, qui peuvent être facilement biaisés par les utilisateurs. Le succès d’une démarche de Change Management se mesure par l’impact réel sur le cycle de vie logiciel et la montée en compétence des équipes :

● Impact sur le Delivery : On cherche à observer une augmentation de la vélocité des équipes (estimée entre +15% et +30%) et une réduction significative du temps passé sur les tâches répétitives (de -20% à -40%). Le but ultime est l’accélération du time-to-market.

● Qualité et Robustesse : Un changement réussi doit se traduire par une diminution des bugs post-mise en production (objectif de -30%) et une augmentation de la couverture de tests automatisés (+20% à +30%).

● Sécurité et Maîtrise : La réussite se mesure aussi par la capacité des équipes à éviter les incidents majeurs, comme l’arrêt accidentel de dossiers en production dû à un script non révisé. Un indicateur innovant peut être le test de résilience via un « Chaos Agent » pour vérifier que les contre-mesures internes bloquent efficacement les agents mal maîtrisés.

● Maturité et Autonomie : Enfin, le succès se valide par l’harmonisation des pratiques et l’atteinte d’une autonomie complète des équipes après la phase de coaching. Le « score de maturité IA » avant et après l’accompagnement reste le juge de paix de la transformation culturelle.

Le « Chaos Agent » en testant la résilience de vos garde-fous

Pour mesurer la maturité d’une organisation face à l’IA, il ne suffit pas de regarder ce qu’elle produit de bien, il faut tester sa capacité à rejeter ce qui est dangereux. C’est ici qu’intervient le concept de Chaos Agent, inspiré du Chaos Engineering.

L’idée est simple : on introduit volontairement dans le workflow de développement un agent IA « malveillant » ou simplement « maladroit ». Son objectif est de tenter de pousser du code qui semble correct en surface mais qui contient des failles critiques : injection SQL, fonctions obsolètes, ou scripts capables de « shutdown » des milliers de dossiers en production.

Vers une transformation du métier de dev

En formant les équipes au Context Engineering et en instaurant une culture de « Human-in-the-loop », on transforme les devs : ils ne subissent plus l’outil, ils deviennent le dernier rempart de la qualité. C’est ainsi que le métier de dev se transforme et ne signifie plus seulement exceller dans les frameworks et les algorithmes, il se transforme en un.e « architecte du contexte » avec une expertise approfondie du produit. Les devs doivent désormais maîtriser l’architecture globale, la stratégie produit et les cas d’usage client pour formuler un « prompt » adéquat.

Le contexte produit (les modèles de données existants, les règles métier spécifiques, les contraintes de sécurité et de performance) est le savoir tacite de l’équipe. Cette expertise devient le nouveau maillon critique de la chaîne de production logicielle, déplaçant la valeur du « savoir coder » vers le « savoir contextualiser ».

L’adoption de l’IA crée ainsi une nouvelle exigence pour les devs : la capacité à coder/reviewer efficacement et la capacité à articuler clairement les besoins du produit pour « guider » l’IA à chaque interaction.