Surf explique pourquoi les équipes sabotent la mise en œuvre de l'IA dans le développement de produits

Les cadres de Surf ont décrit un scénario typique dans lequel les équipes adoptent l'IA dans le développement : du déni aigu à l'équilibre fonctionnel. L'idée principale est que les échecs de mise en œuvre sont souvent liés non pas à la qualité de Copilot, ChatGPT ou Claude, mais à la façon dont les managers gèrent la résistance des gens.

Pas dans la Technologie

Les auteurs de l'article suggèrent de considérer la mise en œuvre de l'IA comme une tâche managériale, et non seulement technique. Selon leurs observations, le même modèle dans une entreprise génère accélération et économies de coûts, tandis que dans une autre il provoque du sabotage silencieux, une utilisation formelle et de la frustration. La différence émerge au moment où un développeur expérimenté cesse d'être un simple exécutant et doit maîtriser un nouveau rôle : confier la tâche à la machine, vérifier le résultat et prendre des décisions, même si la décision semble différente de comment il l'aurait faite. Ce changement de rôle frappe l'identité professionnelle.

Pour certains spécialistes, la valeur a longtemps été construite autour de la compétence personnelle : écrire du code à la main, maintenir le contexte en tête, prendre rapidement des décisions locales. Quand l'IA commence à faire une partie de ce travail, la réaction est souvent perçue non pas comme un intérêt pour un nouvel outil, mais comme une menace pour l'expertise accumulée. C'est particulièrement douloureux pour les forts contributeurs habitués à prouver leur valeur par la qualité de leur propre métier et qui ne sont pas prêts à passer immédiatement au rôle d'orchestrateur ou de relecteur.

Cinq Stades d'Acceptation

Surf relie la réaction de l'équipe à la logique des stades d'acceptation du changement, familière d'après le modèle Kübler-Ross. Les auteurs ne prétendent pas présenter une typologie académique, mais la considèrent comme un cadre pratique commode pour les managers et les leads. Elle aide à distinguir l'adaptation normale du sabotage et à comprendre à quel moment une personne a besoin non d'un autre appel sur les bénéfices de l'IA, mais d'un soutien concret, d'une analyse des erreurs et d'un format plus sûr pour maîtriser un nouvel outil.

• Déni. Un développeur essaie l'IA en supposant qu'il va rapidement prouver son inutilité, et après le premier échec, conclut sur la technologie, non pas sur son approche.
• Colère. Si les collègues réussissent, le désir émerge de dévaloriser le résultat d'un autre et de prouver que ce n'est pas du vrai travail, mais une dangereuse imitation de qualité.
• Marchandage. Pour la première fois, l'idée émerge que le problème peut ne pas être dans l'outil, mais dans la façon dont la personne l'utilise ; c'est le meilleur moment pour le mentorat.
• Euphorie. Après les premiers succès, le pendule bascule de l'autre côté : il semble que maintenant presque tout peut être automatisé et on peut prendre des promesses supplémentaires.
• Équilibre. L'IA cesse d'être soit une menace, soit de la magie et devient simplement un outil de travail avec des limites claires.

« Ça ne marche pas, et je vais te le prouver maintenant. »

Les auteurs soulignent séparément un état intermédiaire où un spécialiste voit déjà les succès des autres, mais au lieu de corriger le processus commence à douter de lui-même. Ce mode ne ressemble pas toujours à de la résistance directe, mais ralentit aussi la mise en œuvre : la personne craint de faire des erreurs, perd d'énergie et tombe dans la simulation d'utilisation au lieu de la pratique réelle. Pour un manager, c'est un signal important : tout résultat faible ne signifie pas l'hostilité, parfois l'équipe manque simplement de retours d'information sûrs et d'un moyen clair d'apprendre de ses erreurs.

Comment Mettre en Œuvre Prudemment

La principale conclusion pratique pour les managers est de ne pas lancer l'IA sur toute l'équipe à la fois. Le déploiement en masse simultané amplifie le déni, la colère et l'euphorie, et le manager ne peut physiquement pas guider chacun à travers ce cycle. Au lieu de cela, Surf conseille de piloter non pas la technologie, mais les gens : choisir ceux qui sont déjà ouverts aux expériences, leur donner des tâches appropriées et les accompagner aux points où surviennent habituellement des erreurs, des attentes déçues ou une surestimation des possibilités.

Les auteurs rappellent aussi que sans un environnement d'apprentissage sûr, l'apprentissage ne décollera pas. Si l'équipe punit immédiatement ou tourne publiquement en dérision tout résultat brut, les employés ne maîtriseront pas honnêtement le nouvel outil. Ils commenceront à cacher les erreurs, à feindre les progrès ou à saboter silencieusement le processus. C'est pourquoi un environnement de travail sain n'est pas ici un slogan RH, mais une condition directe pour l'émergence des premiers cas fonctionnels sur lesquels construire l'expertise interne et changer progressivement l'attitude du reste de l'équipe.

Un autre point important concerne les leaders internes. Quelques exemples remarquables suffisent pour que le reste de l'équipe commence à percevoir l'IA non pas comme une tendance d'en haut, mais comme un vrai moyen de travailler plus vite ou mieux. Un tel exemple réduit la résistance mieux que les réglementations obligatoires, les présentations et l'achat de licences sans un scénario d'application clair. Quand le succès est visible à proximité, la technologie cesse d'être une abstraction et devient un argument fonctionnel au sein de l'équipe.

Ce Que Cela Signifie

Pour les entreprises, c'est un rappel utile : mettre en œuvre l'IA dans le développement n'est pas acheter un autre outil, mais restructurer les rôles, les habitudes et les critères de valeur au sein de l'équipe. Gagnent non pas ceux qui ont formalisé les licences plus vite, mais ceux qui ont pu mener les gens à travers la résistance sans briser leur motivation et transformer l'intérêt pour l'IA en une pratique de travail durable.