Le paradoxe de la confiance : 90% utilisent l'IA, 30% ne lui font pas confiance
90% des développeurs utilisent l'IA. 30% ne lui font pas confiance. Ce paradoxe dit tout.
Il y a quelque chose de profondément révélateur dans ce chiffre. Selon le rapport DORA 2025 — le DevOps Research and Assessment publié par Google en octobre dernier — 90% des développeurs utilisent désormais l'IA au quotidien. C'est une progression de 14 points en un an, soit l'accélération d'adoption la plus rapide jamais observée pour une technologie dans l'histoire du génie logiciel.
Et pourtant. Près d'un tiers de ces mêmes développeurs déclarent ne pas faire confiance à cette technologie qu'ils utilisent chaque jour.
Ce paradoxe n'est pas une anomalie statistique. C'est le signal le plus important que l'industrie devrait lire en ce moment. Il révèle une réalité que les discours enthousiastes sur la "révolution IA" tendent à occulter : l'adoption massive d'une technologie ne garantit pas sa maîtrise, ni même sa pertinence dans un contexte donné. Entre utiliser l'IA et en tirer un avantage réel, il y a un abîme que beaucoup d'équipes techniques sont en train de découvrir à leurs dépens.
Chez SFEIR, nous accompagnons chaque semaine des équipes de développement dans leur transformation. Et ce paradoxe de la confiance, nous le rencontrons sur le terrain bien avant d'en avoir vu les chiffres dans les rapports. Cet article tente d'en décrypter les mécanismes — et de proposer des pistes concrètes pour en sortir.
L'IA comme amplificateur : le mécanisme fondamental que tout le monde sous-estime
La croyance la plus répandue — et la plus dangereuse — est celle-ci : "L'IA va résoudre nos problèmes." Des problèmes de productivité, de délais, de qualité du code, de dette technique. Investissons dans des licences Copilot, formons les équipes, et regardons les métriques décoller.
Le rapport DORA 2025 démonte ce mythe avec une formulation qui mérite d'être gravée dans le marbre de chaque bureau de CTO :
"L'IA est un amplificateur, pas une baguette magique. Elle ne résout aucun problème structurel. Elle les révèle, les accélère, les multiplie."
Ce concept d'amplification IA est le fil conducteur du rapport DORA 2025, et il change radicalement la manière dont on doit aborder l'adoption de ces outils. L'IA opère selon deux dimensions complémentaires :
- L'effet miroir : elle révèle les failles cachées de votre organisation — processus bureaucratiques, dette technique accumulée, silos entre équipes. Ces failles existaient avant. L'IA les rend visibles, souvent douloureusement.
- L'effet multiplicateur : pour les équipes dont les fondations sont solides, elle multiplie la vitesse d'exécution et libère du temps cognitif pour des tâches à plus haute valeur ajoutée.
L'équation est simple à énoncer, redoutable dans ses implications :
- IA + Fondations solides = Performance : accélération exponentielle, stabilité maintenue, innovation libérée.
- IA + Fondations fragiles = Chaos : goulots d'étranglement amplifiés, dette technique explosive, burnout des équipes.
Ce n'est pas une métaphore. C'est une mécanique observable, mesurable, et que nous voyons se jouer concrètement dans les missions que nous menons.
L'embouteillage invisible : quand l'IA révèle vos goulots d'étranglement
Voici un exemple concret pour illustrer l'effet miroir. Avant l'adoption de l'IA générative, une équipe de développement typique passait environ 3 jours à coder une fonctionnalité, puis 3 jours en revue de code. Le processus était lent, mais équilibré. Les goulots d'étranglement existaient, mais ils étaient masqués par la lenteur globale de la chaîne.
Après l'adoption d'outils comme GitHub Copilot ou Cursor, le premier délai s'effondre : 3 heures suffisent là où 3 jours étaient nécessaires. Résultat ? La revue de code reste à 3 jours. Les seniors se retrouvent noyés sous des volumes de code qu'ils ne peuvent plus absorber. La qualité se dégrade. Les délais de livraison ne s'améliorent pas — parfois, ils empirent.
Ce scénario, DORA 2025 le documente précisément. Et ce n'est pas une défaillance de l'IA. C'est une révélation. L'IA a simplement mis en lumière un goulot qui existait déjà, en rendant l'amont du processus tellement plus rapide que l'aval ne peut plus suivre.
La mauvaise réponse à ce problème ? Réduire l'usage de l'IA pour "rééquilibrer". La bonne réponse ? Investir dans les fondations qui permettent d'absorber cette accélération : tests automatisés à couverture complète, pipelines CI/CD robustes avec rollback automatique, infrastructure as code pour provisionner des environnements à la volée.
Sans ces fondations, l'IA ne fait qu'aggraver ce qui était déjà fragile. Avec elles, elle devient un levier de performance sans équivalent.
Le Shadow AI : l'adoption qui se passe sans vous
Le taux d'adoption de 90% cité par DORA 2025 mérite une lecture attentive. Car il ne dit pas que 90% des développeurs utilisent des outils IA approuvés, déployés et monitorés par leurs organisations. Il dit que 90% utilisent l'IA — ce qui inclut une réalité que beaucoup de DSI et de CTOs préfèrent ne pas regarder en face : le Shadow AI.
Le Shadow AI désigne l'ensemble des usages d'outils d'intelligence artificielle qui se développent en dehors des canaux officiels de l'entreprise. Un développeur qui colle des extraits de code propriétaire dans ChatGPT pour déboguer un problème. Une équipe qui utilise Claude ou Gemini pour rédiger des spécifications techniques sans passer par les outils validés. Un tech lead qui génère des tests avec un outil non audité, sans que la DSI en soit informée.
Ces usages ne sont pas marginaux. Ils sont massifs. Et ils posent des questions très concrètes :
- Souveraineté des données : quelles informations sensibles quittent l'entreprise sans contrôle ?
- Conformité : dans un contexte où le règlement DORA européen (Digital Operational Resilience Act, entré en vigueur en janvier 2025) impose des exigences strictes sur la résilience opérationnelle des systèmes, notamment dans le secteur financier, des usages non tracés d'outils IA constituent un risque réglementaire réel.
- Qualité et traçabilité : si du code généré par IA intègre la base de code sans processus de revue adapté, qui est responsable des vulnérabilités introduites ?
Le Shadow AI n'est pas un phénomène de mauvaise volonté. C'est une réponse naturelle à un manque de gouvernance. Les développeurs cherchent à être efficaces. Si l'entreprise ne leur fournit pas les outils, ils les trouvent eux-mêmes. La question n'est donc pas "comment interdire le Shadow AI" mais "comment créer les conditions pour que l'usage de l'IA se fasse dans un cadre maîtrisé et sécurisé".
C'est précisément ce que SFEIR accompagne : la définition d'une politique IA qui ne soit pas un frein mais un cadre, permettant à l'adoption de se faire dans des conditions qui protègent à la fois les équipes et l'organisation.
Pourquoi 30% des utilisateurs ne font pas confiance à l'IA qu'ils utilisent ?
Revenons au paradoxe central. Comment comprendre qu'un développeur utilise quotidiennement un outil dans lequel il n'a pas confiance ?
Plusieurs dynamiques l'expliquent, et elles sont toutes instructives :
La pression implicite de l'adoption
Quand 90% de vos collègues utilisent un outil, ne pas l'utiliser crée une pression sociale et professionnelle. "Tu n'utilises pas Copilot ? Tu vas te faire dépasser." Cette dynamique pousse à l'adoption même en l'absence de conviction. On utilise parce qu'on ne peut pas ne pas utiliser — pas parce qu'on a évalué la valeur ajoutée.
L'expérience de la désillusion
Beaucoup de développeurs ont vécu des situations où l'IA a produit du code plausible mais incorrect, voire dangereux. Un bug subtil introduit par une suggestion non vérifiée. Une vulnérabilité de sécurité ignorée par l'outil. Ces expériences laissent des traces. On continue d'utiliser l'outil — parce qu'il reste utile pour certaines tâches — mais la confiance est érodée.
L'absence de cadre de validation
Faire confiance à un outil, c'est pouvoir évaluer ses sorties. Or, dans de nombreuses équipes, il n'existe pas encore de processus formalisé pour valider le code généré par IA. Comment faire confiance à quelque chose qu'on ne sait pas évaluer systématiquement ? La méfiance est une réponse rationnelle à une situation d'incertitude non outillée.
Le manque de transparence sur le fonctionnement des modèles
Les LLMs sont des boîtes noires. Ils produisent des réponses confiantes sur des sujets sur lesquels ils sont faux. Ils ne signalent pas leurs incertitudes. Pour un développeur formé à la rigueur et à la falsifiabilité du code, cette opacité est intrinsèquement inconfortable.
Ce qui est frappant, c'est que ces 30% de développeurs méfiants ne sont pas des technophobes. Ce sont souvent les plus expérimentés, les plus critiques, ceux qui ont le plus de recul. Leur méfiance n'est pas un problème à corriger — c'est un signal à intégrer dans la stratégie d'adoption.
Les sept capacités qui font la différence : transformer l'IA en avantage durable
Si l'IA amplifie ce qui existe, la question devient : que faut-il construire pour que l'amplification soit positive ? Le rapport DORA 2025 identifie plusieurs capacités organisationnelles qui distinguent les équipes qui tirent vraiment parti de l'IA de celles qui s'y noient.
1. Des pratiques d'ingénierie de qualité en amont
Tests automatisés avec une couverture significative, revues de code structurées, standards de codage documentés. Sans ces pratiques, l'IA génère du volume — pas de la valeur. Avec elles, elle accélère une chaîne déjà fiable.
2. Un pipeline CI/CD mature
Le déploiement continu avec rollback automatique est la condition sine qua non pour absorber la cadence de production d'une équipe augmentée par l'IA. Sans lui, l'accélération crée du chaos opérationnel.
3. Une culture de la mesure
DORA 2025 met en avant le taux de retravail comme nouvelle métrique star de 2025 — un indicateur de la part du code produit qui doit être repris ou corrigé. Dans un contexte d'adoption IA, cette métrique est cruciale : elle révèle si la vitesse de production se fait au détriment de la qualité. Les équipes performantes mesurent, ajustent, et itèrent.
4. Une gouvernance IA explicite
Quels outils sont autorisés ? Pour quels usages ? Avec quelles données ? Qui est responsable de la validation du code généré ? Ces questions ne doivent pas rester dans le flou. Une politique claire réduit le Shadow AI et crée les conditions d'une adoption sereine.
5. La formation au prompt engineering et à l'évaluation critique
Utiliser l'IA efficacement est une compétence. Évaluer ses sorties de manière critique en est une autre. Ces compétences ne s'acquièrent pas spontanément — elles se transmettent, se pratiquent, se formalisent.
6. L'intégration de l'IA dans les flux existants, pas à côté
Les équipes qui réussissent ne créent pas un "espace IA" séparé de leur flux de travail habituel. Elles intègrent les outils directement dans l'IDE, dans le pipeline CI/CD, dans les processus de revue. L'IA devient transparente, naturelle, partie intégrante du métier.
7. Un leadership technique qui assume la complexité
L'adoption de l'IA ne se pilote pas uniquement par des outils. Elle se pilote par des humains qui comprennent à la fois les capacités des modèles, les limites organisationnelles, et les dynamiques d'équipe. Les tech leads et engineering managers jouent un rôle déterminant dans la qualité de l'adoption.
Ce que le paradoxe de la confiance nous apprend sur la maturité organisationnelle
Au fond, ce paradoxe — utiliser sans faire confiance — n'est pas spécifique à l'IA. Il reflète une phase de transition que toute organisation traverse lorsqu'elle adopte une technologie transformatrice plus vite que ses processus ne peuvent l'intégrer.
Nous avons vécu quelque chose de similaire avec l'adoption du cloud public. Les équipes ont commencé à utiliser AWS ou Azure bien avant que les organisations ne disposent des compétences, des processus de gouvernance, et des pratiques de sécurité adaptées. Il a fallu du temps — et des incidents — pour que la maturité suive l'adoption.
Avec l'IA, la vitesse d'adoption est encore plus rapide. 14 points de progression en un an, c'est sans précédent. Les organisations n'ont pas le luxe d'attendre que la maturité se construise naturellement. Elles doivent la construire activement, délibérément, en parallèle de l'adoption.
C'est ici que le concept d'amplification IA prend toute sa dimension stratégique. L'enjeu n'est pas de freiner l'adoption — ce serait illusoire et contre-productif. L'enjeu est de construire, aussi vite que possible, les fondations qui permettront à cette adoption de générer de la valeur plutôt que du chaos.
Les équipes qui réussissent cette transition partagent une caractéristique commune : elles ne traitent pas l'IA comme un projet à part. Elles la traitent comme un révélateur de leur maturité organisationnelle — et elles saisissent l'opportunité pour construire ce qui manquait.
La perspective SFEIR : accompagner la maturité, pas seulement l'adoption
Chez SFEIR, nous avons fait un choix délibéré dans notre approche de l'IA : nous ne vendons pas de la technologie. Nous accompagnons des transformations.
La distinction est essentielle. Déployer des licences Copilot sur l'ensemble d'une organisation en quelques semaines, c'est techniquement trivial. Créer les conditions pour que ces outils génèrent durablement de la valeur — sans introduire de risques cachés, sans créer de dette technique supplémentaire, sans brûler les équipes — c'est une autre histoire.
Concrètement, notre accompagnement sur les sujets d'IA dans le développement logiciel s'articule autour de plusieurs axes :
- Diagnostic de maturité : avant tout déploiement à grande échelle, nous aidons nos clients à évaluer honnêtement leurs fondations — qualité des tests, maturité CI/CD, pratiques de revue de code, culture de la mesure. C'est souvent là que les surprises se cachent.
- Gouvernance IA : nous construisons avec les équipes les politiques d'usage qui permettent de réduire le Shadow AI sans créer de frictions inutiles. L'objectif est toujours de trouver l'équilibre entre sécurité et fluidité.
- Formation et montée en compétence : nous formons les développeurs non seulement à utiliser les outils, mais à évaluer leurs sorties de manière critique. La confiance se construit par la compétence.
- Mesure de l'impact réel : nous aidons à mettre en place les métriques pertinentes — dont le taux de retravail — pour distinguer l'adoption de la performance réelle. Parce qu'utiliser l'IA et en tirer de la valeur sont deux choses différentes.
Le paradoxe de la confiance que révèle DORA 2025 est, en réalité, une opportunité. Les 30% de développeurs qui utilisent l'IA sans lui faire confiance sont précisément ceux qui ont besoin d'un cadre, de processus, et de compétences pour transformer leur scepticisme en usage éclairé. Ce sont souvent les profils les plus précieux dans une stratégie d'adoption réussie — à condition de les écouter plutôt que de les convaincre.
L'ère de l'amplification est là. La vraie question n'est plus "faut-il adopter l'IA ?" — à 90% d'adoption, la réponse est dans les faits. La vraie question est : êtes-vous en train de construire les conditions pour que l'amplification joue en votre faveur ?
La réponse à cette question déterminera, dans les prochaines années, qui transforme l'IA en avantage compétitif durable — et qui découvre, trop tard, que la technologie n'a fait qu'accélérer des fragilités qui auraient mieux valu adresser avant.