L’intelligence artificielle s’est imposée dans les environnements de développement à une vitesse rare dans l’histoire des outils logiciels. En 2025, 84% des développeurs déclarent utiliser ou prévoir d’utiliser des outils IA (contre 76% en 2024), et, chez JetBrains, 85% disent en faire un usage régulier pour coder et développer.
Pourtant, à mesure que l’adoption grimpe, la confiance recule. La même année, seuls 29% affirment faire confiance à la précision des sorties IA (contre 40% en 2024) ; 46% disent au contraire s’en méfier, et à peine 3% « highly trust ». Les développeurs ne sont donc pas « pour ou contre » l’IA : ils sont divisés, souvent à l’intérieur même de leurs pratiques.
1) Adoption en hausse, confiance en baisse : le paradoxe 2025
Le signal le plus frappant est cette dissociation entre usage massif et recul du sentiment favorable. En 2025, l’enquête citée montre un « sentiment » favorable autour de 60%, en baisse après des niveaux supérieurs à 70% en 2023 et 2024. Autrement dit, on utilise davantage l’IA tout en l’aimant moins.
Cette tension se lit aussi dans les chiffres de confiance sur l’exactitude : 46% « distrust » contre 33% « trust », et seulement 3% « highly trust ». Le message implicite est clair : beaucoup de développeurs acceptent l’IA comme outil, mais refusent de lui accorder un statut d’autorité.
Enfin, la prudence augmente avec l’expérience. Les développeurs expérimentés figurent parmi les plus réservés, avec un taux de « highly trust » encore plus faible. L’IA devient un standard de fait, sans devenir un standard de vérité.
2) Des usages ciblés : l’IA acceptée en assistance, refusée sur le critique
La division ne se fait pas seulement entre « utilisateurs » et « non-utilisateurs », mais entre types de tâches. Pour les étapes à forte responsabilité, la résistance reste élevée : 76% ne prévoient pas d’utiliser l’IA pour le déploiement/supervision, et 69% pour la planification de projet.
Ce découpage révèle une adoption pragmatique. L’IA est appréciée pour accélérer, reformuler, suggérer, prototyper, ou automatiser des tâches répétitives. En revanche, quand l’enjeu bascule vers la fiabilité opérationnelle, la gouvernance, ou l’astreinte, la plupart préfèrent garder la main.
Ce n’est pas nécessairement un rejet technologique : c’est une gestion du risque. Dans beaucoup d’équipes, l’IA est « tolérée » pour produire une première version, mais pas pour décider, déployer, ou arbitrer à la place des humains.
3) Le syndrome du « presque correct » et le retour aux sources
La frustration explique une part importante de la défiance. En 2025, 66% des développeurs disent être frustrés par des réponses IA « almost right » : suffisamment plausibles pour donner l’illusion de la justesse, mais suffisamment fausses pour coûter du temps.
Ce phénomène alimente un effet de débordement vers les ressources communautaires. Environ 35% des développeurs indiquent que leurs visites sur Stack Overflow sont dues à des problèmes liés à l’IA au moins « une partie du temps ». L’assistant accélère le démarrage, mais peut augmenter la charge de vérification et de débogage.
Dans la pratique, cela change les réflexes : on ne cherche plus seulement « comment faire », mais « pourquoi l’IA m’a proposé ça » ou « quel est le piège ». L’outil devient un partenaire qui nécessite une contre-expertise constante.
4) Agents IA : promesse forte, adoption encore prudente
Malgré l’enthousiasme médiatique, les « AI agents » ne sont pas encore la norme. En 2025, une majorité (52%) n’utilise pas d’agents ou reste sur des outils IA plus simples, et 38% n’ont pas l’intention d’en adopter. La division est aussi une question de maturité : l’agent autonome implique confiance, cadre, et contrôle.
Les agents touchent à des zones sensibles : accès au dépôt, exécution de commandes, modifications multi-fichiers, interactions avec l’infrastructure. Or, les développeurs ont déjà du mal à faire confiance à la précision d’une simple suggestion ; déléguer une action autonome est un saut qualitatif.
Les équipes qui expérimentent le font souvent avec des garde-fous (environnements isolés, permissions minimales, revues renforcées). Cette prudence explique pourquoi l’IA « copilote » progresse plus vite que l’IA « pilote ».
5) Productivité : gains réels, mesure contestée, ROI débattu
Les gains perçus existent et sont souvent significatifs. Chez JetBrains, « nearly nine out of ten » déclarent économiser au moins une heure par semaine, et 1 développeur sur 5 évoque 8 heures ou plus. Des études rapportent aussi des bénéfices forts sur la documentation, l’autocomplétion et des tâches répétitives (parfois jusqu’à ~50% de temps économisé), avec davantage de difficultés sur des tâches complexes, multi-fichiers ou propriétaires.
Mais la mesure est disputée. JetBrains note que 66% ne croient pas (ou ne sont pas sûrs) que les métriques actuelles reflètent leur contribution réelle. La productivité logicielle ne se réduit pas au débit : il y a la qualité, la maintenabilité, la coordination, la dette technique et le support.
Le débat dépasse les équipes et atteint les directions. En FY26 Q2, Microsoft affirme que l’usage de Copilot a « nearly 3x year-over-year » (DAU) et que GitHub Copilot aurait ~4,7M d’utilisateurs payants (+75% YoY), dans un contexte de CAPEX IA très élevé et de scepticisme sur le ROI. L’adoption « explose », mais la rentabilité et la transformation réelle des processus restent discutées.
6) Qualité et coordination : les gains peuvent déplacer les coûts
Des résultats de recherche récents nuancent l’histoire d’une accélération « gratuite ». Un préprint (2025) sur l’open source attribue à Copilot une hausse de productivité projet (+6,5%) et individuelle (+5,5%), ainsi qu’une participation en hausse (+5,4%). Mais il observe aussi une augmentation du temps d’intégration de +41,6% : plus de travail de coordination, de revue, ou de fusion.
Dans une expérimentation contrôlée (151 participants, majoritairement des professionnels), la phase initiale montre une réduction médiane de 30,7% du temps de complétion avec assistant IA. Mais, lors d’une phase où d’autres développeurs sans IA devaient faire évoluer le code, les différences en temps/qualité ne sont pas significatives, et les gains sur la maintenabilité sont jugés « small and highly uncertain ».
Ces résultats nourrissent la division : certains voient une accélération nette sur la production de code, d’autres constatent que l’effort se déplace vers la revue, la compréhension, et l’intégration. L’IA peut augmenter le débit local tout en créant de la friction systémique.
7) Sécurité : confiance déclarée, frein réel, risques documentés
La sécurité est l’un des points où les contradictions sont les plus fortes. Selon Snyk (2025), 63,3% évaluent la sécurité du code généré par IA comme « excellent » ou « good ». Pourtant, environ 58% citent la sécurité comme la plus grande barrière à l’adoption, signe qu’entre perception générale et responsabilité opérationnelle, la prudence reprend le dessus.
Des travaux relayés par Veracode (2025, via article) avertissent qu’une part importante du code IA « prêt pour la production » peut rester vulnérable : ~45% du code généré contiendrait des failles, avec de mauvais résultats sur certaines classes (XSS, log injection), et pas d’amélioration nette avec des modèles plus récents/grands selon l’article. Cela alimente la crainte d’un vernis de crédibilité masquant des risques.
À l’échelle de l’écosystème, Sonatype (via article) souligne l’explosion de l’échelle open source et de la surface d’attaque : 9,8 trillions de téléchargements de composants en 2025 (+67% YoY) et 454 648 packages malveillants identifiés sur la seule année 2025 (1,23M au total). Dans ce contexte, les hallucinations de dépendances/versions et l’automatisation par IA peuvent amplifier les erreurs plutôt que les réduire.
8) Divisions sociales et culturelles : expérience, pays, consentement et “IA imposée”
Les différences se voient aussi dans les données d’usage à grande échelle. Une analyse (fin 2024) d’environ 30M contributions GitHub estime la progression de l’« AI-assisted coding » aux États-Unis d’environ ~5% (2022) à ~30% (fin 2024). Elle avance aussi des disparités par pays : France ~24%, Allemagne ~23%, Inde ~20%, Russie ~15%, Chine ~12%.
La fracture suit également l’expérience : les développeurs moins expérimentés utiliseraient davantage l’IA (37%) que les plus expérimentés (27%), mais ces derniers en tireraient davantage de bénéfices en productivité et élargissement des compétences, selon l’article résumant l’étude. Cela peut s’expliquer par la capacité des seniors à mieux cadrer les demandes, vérifier, et intégrer sans se faire piéger par le « presque correct ».
Enfin, une partie du rejet est politique et ergonomique : certains développeurs se disent hostiles à des fonctionnalités Copilot « forced upon them », jugées intrusives ou difficiles à désactiver (génération automatique, issues, reviews), avec des critiques sur la qualité, le consentement d’entraînement et l’éthique. Même quand l’IA est utile, la façon dont elle est déployée peut cristalliser l’opposition.
9) « On utilise quand même » : le dilemme de la vérification et de la responsabilité
Le cœur de la division tient peut-être en une phrase : on adopte, mais on ne croit pas complètement. Un article (2026/2025) décrivant un sondage Sonar indique que 96% ne font pas totalement confiance au code IA, alors que seuls 48% déclarent « toujours » vérifier avant commit. Cet écart entre prudence déclarée et discipline réelle inquiète.
Dans les équipes, la responsabilité reste humaine : en cas d’incident, de faille, ou de régression, c’est le processus (revue, tests, CI, sécurité) qui tranche, pas l’outil. Mais l’IA peut introduire une « dette de compréhension » : du code accepté parce qu’il compile et passe les tests, sans être pleinement compris.
La division est donc aussi une question d’organisation : clarifier quand utiliser l’IA, comment tracer ce qui a été généré, quelles règles de revue appliquer, et comment éviter que la vitesse ne dégrade la maîtrise. Les développeurs ne refusent pas l’IA ; ils refusent d’en assumer les risques sans garanties.
L’IA dans le développement logiciel n’est ni une mode passagère ni une baguette magique. Les chiffres récents décrivent une industrie entrée dans l’usage quotidien (84, 85% d’adoption selon les enquêtes), tout en voyant la confiance reculer (29% seulement font confiance à l’exactitude, 46% s’en méfient) et la frustration monter (66% face au « presque correct »).
Cette division est rationnelle : l’IA accélère certaines tâches, mais déplace les coûts vers la vérification, la coordination et la sécurité ; elle aide à produire plus vite, mais ne garantit ni la vérité ni la robustesse. La prochaine étape ne sera pas seulement technique (meilleurs modèles), mais surtout pratique : règles d’usage, garde-fous, métriques adaptées, et consentement clair, pour que l’outil devienne un levier, pas un facteur de risque.