Chez Thunders, nous avons interrogé 30 CTOs et 36 autres dirigeants tech pour dépasser le battage médiatique autour de l'IA et comprendre ce dont les équipes de développement ont réellement besoin.
Il ne s'agissait pas d'une étude sectorielle exhaustive, mais d'une conversation ciblée avec ceux qui signent les chèques pour de nouveaux outils et qui vivent avec les conséquences de la dette technique.
Ce qui en est ressorti ? Le portrait d'une industrie aux prises avec des tensions fondamentales entre ambition et exécution.
Pourquoi la perspective des CTOs compte
Les CTOs représentaient 45,5 % de nos répondants, les CEOs 28,8 % et les CPOs 10,6 %.
Ce sont les dirigeants qui prennent les décisions technologiques et en assument la responsabilité.
Quand un CTO affirme que recruter de bons ingénieurs est son défi n°1 (15,1 %), il ne se plaint pas simplement d'un marché de l'emploi tendu. Il admet que son équipe actuelle ne peut pas évoluer pour répondre à ses ambitions.
Quand ils classent la supervision de la production et les tests logiciels comme préoccupations ex-æquo (13,6 % chacun), ils révèlent quelque chose de plus inconfortable : ils déploient du code dont ils n'ont pas pleinement confiance, et ils ne sont pas certains de détecter les problèmes avant que les clients ne les rencontrent.
Ce que la stack technologique révèle de ces entreprises
The technology choices reveal the age and nature of these organizations. GitHub dominates version control at 49%, but the CI/CD landscape fragments across GitHub Actions (35% combined), Jenkins (19%), and a long tail of alternatives (23% using "other" solutions).
This fragmentation reflects companies at different maturity stages, each having made different bets on their pipeline infrastructure.
React leads at 17%, TypeScript at 16%, NodeJS at 13%, a modern JavaScript-heavy stack that confirms these are relatively young companies (average age: 6 years).
The near-absence of .NET (4%) isn't a commentary on Microsoft's technology; it's a demographic signal.
These companies were born in the cloud-native era.
The deployment platforms reinforce this: AWS leads at 28%, but 13% are deploying to mobile apps, and only 4% to desktop applications. These aren't enterprises maintaining legacy systems: they're companies racing to ship web and mobile products.
Le paradoxe de l'automatisation
Interrogés sur la valeur de divers outils d'automatisation, les participants ont révélé une hiérarchie fascinante qui expose le fossé entre désir et conviction :
Tests logiciels automatisés:
71.2% l'ont jugé “extrêmement” ou “très” précieux
Ce n'est pas surprenant. Les tests sont pénibles, chronophages, et tout le monde sait qu'il faudrait en faire davantage. La demande est claire et la douleur est aiguë.
Priorisation produit:
La pratique vs. la promesse
Seulement 33,3 % des répondants ont jugé la priorisation produit comme une pratique très précieuse dans leur processus de développement (la note la plus basse parmi toutes les pratiques interrogées).
Pourtant, lorsqu'on les interroge sur la priorisation produit assistée par IA en tant qu'outil d'automatisation, 65,1 % l'ont jugée très précieuse.
Cet écart est fascinant.
Les équipes ne valorisent pas particulièrement la priorisation produit qu'elles font elles-mêmes, mais elles voient un potentiel massif à ce que l'IA la fasse pour elles.
Cela suggère deux choses : soit les approches manuelles actuelles de priorisation sont si pénibles et inefficaces que les équipes préféreraient la déléguer entièrement, soit les équipes reconnaissent que la priorisation compte mais manquent de confiance dans leur propre capacité à bien la faire.
Dans tous les cas, c'est un appel à l'aide déguisé en enthousiasme pour l'automatisation.
Revues de code assistées par IA:
57.7% de valeur élevée, mais 83 % reconnaissent une certaine valeur
C'est le point de données le plus révélateur. Les revues de code ont obtenu la réception positive la plus cohérente, mais se classent plus bas dans les évaluations "extrêmement précieux".
Pourquoi ? Parce que les équipes reconnaissent que les revues de code comptent énormément, mais elles ne sont pas convaincues que l'IA puisse réellement bien les faire. C'est une conviction tempérée par l'expérience vécue avec des outils qui surpromettent.
Documentation assistée par IA:
53 % de valeur élevée
Le fait que la documentation soit classée la plus basse parmi les outils d'automatisation est révélateur. Tout le monde déteste écrire de la documentation, mais seulement la moitié environ croit que l'IA peut résoudre ce problème. L'autre moitié a probablement essayé la documentation auto-générée et l'a trouvée inutile. Techniquement exacte mais contextuellement vide.
Ce que la question de la "baguette magique" a révélé
Quand nous avons demandé ce que les répondants automatiseraient s'ils le pouvaient, les réponses se sont regroupées de manière prévisible autour des tests, des revues de code, de la documentation et de la détection de bugs, c'est-à-dire les points de douleur visibles.
Mais enfouies dans les réponses se trouvaient des aperçus de frustrations plus profondes : automatiser la traduction des retours clients, les études de marché et les entretiens utilisateurs.
Ce ne sont pas des problèmes d'ingénierie : ce sont des problèmes produit.
Certains répondants veulent automatiser l'ensemble du processus de découverte et de validation. Ils ne cherchent pas seulement du code plus rapide ; ils cherchent une certitude plus rapide sur quoi construire.
Cela révèle une intuition cruciale : les dirigeants les plus frustrés par leurs défis d'ingénierie se battent souvent avec des défis produit en amont. Ils essaient de résoudre "nous construisons lentement" alors que le vrai problème pourrait être "nous construisons les mauvaises choses."
La barrière à l'adoption : ce n'est pas ce que vous pensez
Le coût s'est classé comme le facteur n°1 influençant les décisions d'adoption de l'IA (22 %), suivi immédiatement par la facilité d'intégration (21 %). Le ROI démontré arrive en troisième position à seulement 17 %.
Cet ordre est à l'inverse d'une prise de décision rationnelle. Le ROI devrait dominer. Mais ce n'est pas le cas, parce que les équipes ne font plus confiance aux projections de ROI.
Elles ont été échaudées par des outils qui promettaient 40 % de gains de productivité et ont livré des cauchemars d'intégration, des perturbations de workflow et des améliorations marginales noyées dans le bruit.
Elles ont donc appris à commencer par les questions tangibles : "Combien ça coûte ?" et "Combien de douleur ça va causer ?" avant même d'aborder "À quel point c'est efficace ?"
Les préoccupations de sécurité et de confidentialité se sont classées à 15 % (étonnamment plus bas que prévu). Cela suggère soit que les équipes font confiance aux fournisseurs d'IA modernes pour gérer les données de manière responsable, soit, plus inquiétant, qu'elles n'ont pas pleinement intériorisé ce que signifie envoyer leur base de code à un système d'IA tiers (aïe).
Perspectives à 3-5 ans : automatisation vs. transformation
31 % des répondants voient l'IA principalement améliorer l'automatisation et la productivité.Gérer les tâches routinières, améliorer la qualité du code et rendre les développeurs plus rapides dans ce qu'ils font déjà.
C'est la vision optimiste et incrémentale. L'IA comme outil de puissance.
Mais 24 % anticipent une transformation fondamentale des rôles d'ingénierie.Ces répondants ne parlent pas de développeurs qui écrivent du code plus rapidement ; ils parlent du métier lui-même qui change. Que fait un ingénieur logiciel quand l'IA gère l'implémentation ?
Quand près d'un quart des dirigeants tech s'attendent à une transformation des rôles, ce n'est pas du bruit de fond : c'est un signal d'alerte sismique.
19 % supplémentaires s'attendent à une intégration plus profonde de l'IA dans les environnements de développement eux-mêmes. Ils imaginent des IDE qui ne se contentent pas d'autocompléter mais participent activement aux décisions architecturales, qui ne suggèrent pas seulement des corrections mais comprennent les implications système.
14 % se sont concentrés sur l'impact de l'IA sur le développement produit en utilisant l'IA pour déterminer quoi construire, pas seulement comment le construire.
Et 12 % ont exprimé une incertitude réelle, ce qui pourrait être la réponse la plus honnête.
Ce que ces données nous disent vraiment
Les contradictions comptent plus que le consensus.
Les équipes veulent désespérément des tests automatisés (71 % de valeur élevée) mais restent sceptiques sur les revues de code IA (57 % de valeur élevée malgré 83 % reconnaissant une certaine valeur). Pourquoi cet écart ? Les tests semblent être un problème résolu qui nécessite juste de l'exécution. Les revues de code nécessitent jugement, contexte et compréhension des conséquences, des choses que l'IA n'a pas prouvé pouvoir livrer de manière fiable.
Les dirigeants peinent avec le recrutement (15,1 % de défi principal) mais montrent des points de vue incohérents sur la priorisation produit. Vous ne pouvez pas recruter efficacement si vous ne savez pas ce que vous construisez ni pourquoi. La crise du recrutement pourrait être en aval d'une crise de stratégie.
Ils mènent les décisions d'adoption avec des préoccupations de coût et d'intégration plutôt que de ROI, révélant une industrie à qui on a trop vendu et qui a été sous-livrée à répétition. La confiance s'est érodée plus vite que la capacité ne s'est améliorée.
Ils sont divisés presque également entre évolution et révolution, avec près d'un quart s'attendant à ce que leurs rôles se transforment fondamentalement d'ici cinq ans, tandis qu'un tiers s'attend à une amélioration incrémentale.
Ce n'est pas un désaccord sur les faits ; ce sont des visions et des processus de pensée réellement différents du futur.
La vraie question
Ces données ne montrent pas une industrie qui a compris l'IA dans le développement logiciel.
Elles montrent une industrie en train de le comprendre, avec toute l'incertitude, les contradictions et l'optimisme prudent que cela implique.
La question n'est pas de savoir si l'IA changera le développement logiciel. Les preuves en ce sens sont accablantes. La question est de savoir si les outils construits aujourd'hui résolvent les problèmes que les équipes ont réellement, ou les problèmes que les fournisseurs supposent qu'elles devraient avoir.
Quand les CTOs disent qu'ils valorisent les tests automatisés à 71 % mais les revues de code IA à seulement 57 %, ils ne sont pas contradictoires. Ils nous disent exactement où se situe le fossé de crédibilité. Ils croient en l'automatisation là où ils l'ont vue fonctionner. Ils sont sceptiques là où ils l'ont vue échouer.
Les entreprises qui comblent ce fossé (qui livrent un ROI réel avec une douleur d'intégration minimale sur les problèmes que les équipes ressentent réellement) ne gagneront pas seulement des parts de marché. Elles redéfiniront ce que signifie le développement logiciel.
À propos de cette recherche :
Thunders a interrogé 66 dirigeants tech, dont 30 CTOs, 19 CEOs et 7 CPOs d'entreprises ayant en moyenne 6 ans d'existence. L'enquête s'est concentrée sur des décideurs ayant à la fois l'autorité budgétaire et la profondeur technique pour comprendre les modèles d'adoption réels plutôt que les tendances aspirationnelles du secteur.