Surf explique pourquoi les équipes sabotent l'adoption de l'IA dans le développement de produits

Des dirigeants de Surf ont décrit le scénario type par lequel les équipes acceptent l'IA dans le développement : d'un déni brutal à un équilibre de travail. L'idée centrale : les échecs d'adoption tiennent plus souvent à la façon dont les managers gèrent la résistance des personnes qu'à la qualité de Copilot, ChatGPT ou Claude.

Ce n'est pas une question de technologie

Les auteurs proposent de voir l'adoption de l'IA comme un problème de management, et pas seulement technique. D'après leurs observations, le même modèle apporte accélération et économies dans une entreprise, et provoque dans une autre un sabotage discret, un usage de façade et de l'irritation.

La différence apparaît quand un développeur expérimenté cesse d'être un simple exécutant et doit endosser un nouveau rôle : confier la tâche à la machine, vérifier le résultat et trancher, même si la décision ne ressemble pas à celle qu'il aurait prise lui-même.

Ce changement de rôle touche à l'identité professionnelle. Pour certains spécialistes, la valeur s'est longtemps construite autour d'un savoir-faire personnel : écrire le code à la main, garder le contexte en tête, prendre vite une décision locale. Quand l'IA se met à faire une partie de ce travail, la réaction est souvent vécue non comme de l'intérêt pour un nouvel outil, mais comme une menace pour l'expertise accumulée. C'est particulièrement douloureux pour les bons exécutants, habitués à prouver leur valeur par la qualité de leur propre métier et qui ne sont pas prêts à passer d'emblée en mode orchestrateur ou relecteur.

Cinq étapes d'acceptation

Surf rattache la réaction de l'équipe à la logique des étapes d'acceptation du changement, connue grâce au modèle de Kübler-Ross. Les auteurs ne prétendent pas proposer une typologie académique, mais la jugent commode comme cadre pratique pour les managers et les leads. Elle aide à distinguer une adaptation ordinaire du sabotage et à comprendre quand une personne a besoin, plutôt que d'une énième réunion sur les bénéfices de l'IA, d'un soutien concret, d'une analyse des erreurs et d'un format plus sûr pour apprivoiser l'outil.

• Déni. Le développeur essaie l'IA persuadé de prouver vite son inutilité et, après le premier échec, tire une conclusion sur la technologie plutôt que sur sa propre approche.
• Colère. Si des collègues réussissent quelque chose, l'envie surgit de dévaloriser leur résultat et de démontrer que ce n'est pas du vrai travail, mais une imitation dangereuse de qualité.
• Marchandage. Pour la première fois, l'idée apparaît que le problème ne vient peut-être pas de l'outil, mais de la manière dont la personne l'utilise ; c'est le meilleur moment pour le mentorat.
• Euphorie. Après les premiers succès, le balancier part de l'autre côté : on a l'impression de pouvoir désormais tout automatiser ou presque et l'on prend des engagements de trop.
• Équilibre. L'IA cesse d'être une menace ou de la magie et devient simplement un outil de travail aux limites claires.

«

Ça ne marche pas, et je vais vous le prouver tout de suite. »

Les auteurs isolent aussi un état intermédiaire : le spécialiste voit déjà les réussites des autres mais, au lieu d'ajuster le processus, se met à douter de lui. Ce mode ne ressemble pas toujours à une résistance frontale, mais il freine aussi l'adoption : la personne craint de se tromper, perd son énergie et se contente de simuler l'usage au lieu de pratiquer réellement. Pour un responsable, c'est un signal important : un mauvais résultat n'est pas forcément signe d'hostilité ; parfois, l'équipe manque simplement de retours sans risque et d'un moyen clair d'apprendre de ses faux pas.

Comment déployer avec prudence

La principale leçon pratique pour les managers : ne pas lancer l'IA sur toute l'équipe d'un coup. Un déploiement massif amplifie en même temps le déni, la colère et l'euphorie, et le responsable n'a matériellement pas le temps de guider chacun à travers ce cycle. Surf conseille plutôt de piloter non la technologie, mais les personnes : choisir celles qui sont déjà ouvertes à l'expérimentation, leur confier des tâches adaptées et les accompagner aux moments où surviennent d'ordinaire les erreurs, les attentes déçues ou la surestimation des capacités.

Les auteurs rappellent aussi que sans environnement sûr, l'apprentissage ne décolle pas. Si, dans l'équipe, tout résultat brut est aussitôt sanctionné ou tourné en ridicule en public, les employés n'apprendront pas l'outil honnêtement. Ils cacheront leurs erreurs, feindront de progresser ou saboteront le processus en silence. Un environnement de travail sain n'est donc pas ici un slogan RH, mais une condition directe pour obtenir les premiers cas concrets, sur lesquels bâtir une expertise interne et faire évoluer peu à peu l'attitude du reste de l'équipe.

Un autre point important concerne les leaders internes. Quelques exemples visibles suffisent pour que le reste de l'équipe voie l'IA non comme une mode venue d'en haut, mais comme un moyen réel de travailler plus vite ou mieux. Un tel exemple réduit la résistance mieux que des règlements obligatoires, des présentations et l'achat de licences sans scénario d'usage clair. Quand la réussite se voit à côté de soi, la technologie cesse d'être abstraite et devient un argument de travail au sein de l'équipe.

Ce que cela signifie

Pour les entreprises, c'est un rappel utile : adopter l'IA dans le développement, ce n'est pas acheter un outil de plus, mais remodeler les rôles, les habitudes et les critères de valeur au sein de l'équipe. Les gagnants ne sont pas ceux qui signent les licences le plus vite, mais ceux qui parviennent à accompagner les gens à travers la résistance, sans casser leur motivation, et à transformer l'intérêt pour l'IA en pratique de travail durable.