Le syndrome de l’imposteur gagne les salariés utilisant l’IA : pourquoi ce malaise monte au travail

L’IA générative promet un vieux rêve des équipes IT : accélérer la production sans rogner la qualité. Pourtant, à mesure que les copilots entrent dans les workflows, un malaise discret remonte à la surface : celui de ne plus très bien savoir où commence sa propre contribution. Quand un livrable sort plus vite, avec une part croissante d’assistance machine, la question du mérite devient moins claire. Ce brouillage nourrit une forme renouvelée du syndrome de l’imposteur, bien plus concrète qu’un simple manque de confiance.

L’IA change le rapport au mérite plus qu’elle ne change le travail

Une aide précieuse… qui brouille l’attribution du résultat

L’IA n’a pas inventé le syndrome de l’imposteur. Elle lui a donné un visage plus contemporain, plus ambigu aussi. 

Le doute ne porte plus seulement sur la compétence brute — « suis-je vraiment à la hauteur ? » — mais sur l’origine réelle de ce que l’on livre. Dans un environnement où un prompt bien cadré, un agent bien configuré ou un copilote bien utilisé accélèrent une séquence entière de travail, la question du mérite se pose. Elle devient moins abstraite : quelle part de ce résultat vient encore de moi ?

Les chiffres remontés par l’étude OpinionWay pour Factorial montrent que ce malaise n’a rien d’un épiphénomène. En France, 45 % des moins de 35 ans déclarent déléguer désormais une part majeure de leur travail à l’IA. 

Plus troublant encore, 26 % des salariés — et 47 % des moins de 35 ans — reconnaissent présenter comme les leurs des contenus largement produits par ces outils. Le glissement psychologique apparaît nettement dans un autre indicateur : 22 % disent avoir déjà ressenti de la gêne ou de la honte à être félicités pour un travail réalisé avec l’aide de la machine ; chez les jeunes actifs, ce taux grimpe à 41 %. 

Enfin, 23 % expliquent ne plus toujours savoir si une idée vient d’eux ou de l’IA.

Ce déplacement compte parce qu’il touche au cœur du travail intellectuel. Dans beaucoup de métiers, l’outil accélère une tâche. Dans l’IT, il intervient souvent dans ce qui fonde la légitimité même du professionnel : structurer un raisonnement, écrire du code exploitable, documenter une décision technique, déboguer, explorer un framework peu familier, reformuler une architecture, préparer une migration. 

Pourquoi ce malaise prend de l’ampleur dans les métiers IT ?

Dans un métier où la crédibilité repose autant sur la vitesse d’exécution que sur la profondeur de compréhension, l’IA introduit une tension assez brutale. Le livrable sort plus vite ; la maîtrise intime, elle, ne progresse pas nécessairement au même rythme. 

Un développeur peut générer un composant, refactorer une couche de service, écrire un script d’automatisation ou préparer une documentation technique en quelques itérations. Le résultat tient parfois la route. Le problème surgit juste après : comprendre assez finement ce qui a été produit pour l’assumer, le maintenir, le sécuriser et le reprendre sans béquille.

Les retours terrain observés chez des développeurs expérimentés vont tous dans la même direction. Certains décrivent la sensation de ne plus connaître réellement leur codebase. 

D’autres expliquent qu’un bug en production devient plus difficile à assumer quand le code a été majoritairement généré, puis vaguement retouché à la main. 

D’autres encore résument le basculement d’un mot : ils se sentent davantage superviseurs qu’auteurs. Cette nuance n’a rien d’esthétique. Dans l’ingénierie logicielle, la responsabilité, elle, ne se déplace pas vers l’outil. Quand un module casse, quand une régression remonte, quand une faille passe en revue, c’est toujours l’équipe humaine qui répond.

Ce décalage nourrit le syndrome de l’imposteur d’une manière très spécifique. L’angoisse ne naît pas forcément d’une ignorance totale. Elle naît d’une maîtrise partielle, parfois suffisante pour livrer, insuffisante pour se sentir pleinement légitime. 

Cela explique pourquoi des profils seniors, habituellement peu enclins à douter de leurs fondamentaux, disent ressentir une forme de crise existentielle face à la cadence nouvelle des outils. Ils savent cadrer, corriger, challenger, mais sentent aussi que la part d’exécution directe se réduit — et avec elle un vieux repère de confiance.

Le problème n’est pas seulement l’outil, mais aussi le manque de cadre

Il serait trop commode d’accuser la seule technologie. Le malaise prend aussi de l’ampleur parce que les entreprises déploient souvent l’IA sans doctrine claire. Toujours selon l’étude OpinionWay pour Factorial, 56 % des salariés estiment que leur entreprise les laisse se débrouiller seuls avec ces outils, sans règles ni cadre précis. Dans les ETI, ce taux grimpe à 61 % ; dans les grands groupes, à 58 %. 

L’usage se diffuse vite, la gouvernance suit mal.

C’est là qu’entre en scène le shadow AI. On parle beaucoup du risque de confidentialité ou de conformité, à juste titre. 

Il existe aussi un effet plus diffus, presque silencieux : quand chacun improvise sa méthode, son niveau de délégation et ses garde-fous, chacun improvise aussi sa légitimité. 

Un développeur s’appuie massivement sur un agent de code sans savoir jusqu’où cela reste acceptable. 

Un data analyst laisse un LLM structurer une partie de son analyse, puis hésite sur la manière de présenter son travail. 

Un administrateur systèmes se repose sur des scripts générés plus qu’il ne l’aurait admis six mois plus tôt. Tant qu’aucune règle collective ne borne les usages, la norme se déplace en sous-main. Et plus elle se déplace sans être nommée, plus la reconnaissance extérieure devient inconfortable...

Quelles conséquences chez les salariés et dans les équipes ?

Côté salarié : gêne, dépendance, perte de repères

Il y a la gêne à recevoir du crédit pour un travail perçu comme « co-écrit ». Il y a la peur d’être démasqué si l’on doit tout reprendre sans assistance. Il y a, aussi, une impression plus insidieuse : celle de tricher sans fraude caractérisée, de réussir sans internaliser vraiment la réussite. Le professionnel ne doute pas nécessairement de son intelligence. Il doute de sa part propre dans la performance.

Côté équipe : faux gains de productivité et dette de compréhension

L’autre effet, moins commenté, touche l’équipe elle-même. L’IA fait parfois gagner du temps, sans discussion. Mais ce gain reste loin d’être linéaire. L’enquête montre que 41 % des salariés observent un effet de vases communicants : du temps gagné d’un côté, du temps reperdu ailleurs, notamment dans la vérification, la reformulation ou le prompting. 

Et 24 % reconnaissent passer trop de temps à peaufiner les réponses de l’IA au lieu de faire progresser réellement leurs dossiers.

Dans un collectif IT, cette ambivalence se traduit souvent par une dette de compréhension. Le code arrive plus vite. La doc se rédige plus vite. Les tickets se ferment plus vite. En revanche, la maintenabilité, la capacité à expliquer les choix, la lisibilité des modules et l’appropriation réelle de la stack peuvent s’éroder. 

Comment éviter que l’IA n’alimente le syndrome de l’imposteur ?

Redéfinir la valeur réelle d’un professionnel IT

La sortie par le haut passe par une redéfinition plus nette de la valeur professionnelle. Dans l’IT, cette valeur ne réside plus seulement dans le fait d’écrire soi-même chaque ligne, ni même dans la pure vélocité d’exécution. Elle se loge désormais dans le cadrage d’un besoin, le choix d’architecture, la revue critique, les tests, la sécurité, l’observabilité, la capacité à relire un résultat douteux, à détecter une hallucination technique, à reprendre la main sans délai quand l’outil déraille. C’est moins spectaculaire qu’un écran qui se remplit tout seul. Mais c’est aussi bien plus solide.

Trois garde-fous concrets pour rester compétent avec l’IA

Premier garde-fou : ne rien livrer que l’on ne sache pas expliquer. La règle paraît sévère ; elle protège pourtant mieux qu’une charte abstraite. Si un développeur ne peut pas exposer clairement la logique d’un module, ses dépendances, ses effets de bord ou ses compromis, l’outil a déjà pris trop de place dans la chaîne de décision.

Deuxième garde-fou : conserver des zones de pratique sans assistance. Pas pour cultiver une nostalgie du « tout manuel », mais pour entretenir les réflexes. Écrire certains scripts sans copilote, mener un debugging sans appel immédiat à un LLM, relire une PR en repartant du raisonnement plutôt que de la seule sortie proposée… : ce sont des exercices de maintien en condition, au sens presque sportif du terme. Ils évitent que l’expertise ne rouille à bas bruit.

Troisième garde-fou : mesurer autre chose que la vitesse. Une équipe qui ne suit que le nombre de tickets clôturés ou le throughput nourrit mécaniquement le problème. Une équipe qui regarde aussi la qualité de la revue, le taux de reprise, la robustesse des tests, etc. ramène l’IA à sa juste place : un levier, pas une caution identitaire.

L’IA, une machine à générer du syndrome de l’imposteur ?

L’IA ne vide pas les métiers de la Tech de leur substance. Elle déplace le centre de gravité. Et c’est précisément ce déplacement qui déstabilise. Le risque n’est pas de travailler avec des outils plus puissants ; le risque consiste à laisser ces outils redéfinir en silence ce qui compte dans le travail bien fait. À partir de là, le syndrome de l’imposteur trouve un terrain idéal : plus de vitesse, moins de repères, et une responsabilité qui, elle, reste intégralement humaine.

👉 Le marché évolue vite, les opportunités aussi. Découvrez les offres IT et Tech actuellement disponibles sur Free-Work.