Pourquoi le déficit de compétences IA d'une équipe est difficile à identifier ? (1/3)

On forme et on recrute sur ce qui se nomme, pas sur ce qui décide. Trois études convergent sans jamais relier formation, recrutement et pilotage IA.

A peine plus de 4,5 % des offres d’AI Engineer exigent de savoir évaluer un système d’intelligence artificielle. Or 64 % des dirigeants citent l’évaluation comme premier obstacle avant la mise en production de leur système. Relions les deux chiffres.

Cet article est le premier volet d’une série de trois consacrée aux compétences IA en entreprise : ce diagnostic pose le manque, la grille de compétences pose une référence, le plan d’action le rend opérant.

Ce que trois études mesurent sans le relier

AI Shipping Labs ↗ a classifié 889 offres d’emploi « AI Engineer » collectées début 2026 à Berlin, Amsterdam, Londres, Los Angeles et New York. Sa définition de synthèse du métier place l’évaluation et la qualité parmi les quatre responsabilités centrales de la fonction. Dans les offres réelles, elle n’apparaît que dans 4,5 % des cas comme compétence explicitement requise. Le RAG (retrieval-augmented generation), lui, figure dans 35,9 % des offres. Je fais l’hypothèse qu’il en est ainsi parce que le concept s’est démocratisé et qu’il est régulièrement évoqué comme point de passage obligé pour valoriser le capital informationnel d’une entreprise.

L’APEC ↗, dans son enquête « Les cadres et l’IA » (21 mai 2026), mesure que la moitié des cadres français utilisent l’intelligence artificielle chaque semaine, soit 15 points de plus qu’un an plus tôt. Seuls 29 % déclarent avoir été formés, et ces formations restent majoritairement généralistes plutôt que centrées sur un métier.

Enfin, les données de production mi-2026, attribuées à Forrester et Anaconda et relayées de seconde main par un article de synthèse ↗ (le rapport primaire est sous paywall à 1500 dollars, non consulté directement…), donnent 88 % des pilotes d’agents qui n’atteignent jamais la production, avec l’évaluation comme premier blocage cité par 64 % des dirigeants interrogés.

Trois publications, trois échelles (le marché du recrutement, la formation individuelle, le pilotage d’entreprise). Elles ne mesurent pas le même objet, avec les mêmes méthodes, sur les mêmes géographies : le rapprochement qui suit est donc davantage structurel, que statistique. Ce sont trois symptômes du même mécanisme, et non trois preuves d’un seul phénomène. Aucune des trois publications ne nomme ce mécanisme.

Étage 1 : la formation enseigne ce qui se vend

Le prompt engineering et ses dérivés est la matière la plus enseignée sur la thématique l’intelligence artificielle, mais la moins déterminante pour faire aboutir un projet (c’est moi qui le dis). Ce n’est pas un hasard de marché mais une conséquence structurelle de ce qui peut devenir un produit de formation. Le prompting s’enseigne en une journée, voire deux, se certifie, se facture… Le jugement critique, qui consiste à juger si une sortie de modèle est correcte avant de l’utiliser, n’est couvert par aucune de ces dimensions.

On pourrait objecter que l’évaluation est simplement moins certifiable que le prompting, et qu’elle resterait sous-représentée quel que soit le vocabulaire disponible. On touche ici à ce que l’économiste David Autor a nommé le paradoxe de Polanyi ↗ (MIT, 2014) : les compétences les plus résistantes à la formalisation sont aussi les plus résistantes à l’enseignement en package. Sauf que le tacite dont parle Polanyi n’est pas un déficit provisoire de formalisation, c’est une résistance structurelle à la mise en mots, pas à la mise en preuve. L’évaluation a des approximations mesurables : un taux de faux positifs, des points de validation successifs qui échouent ou qui tiennent. Ce qui manque n’est pas une mesure, c’est un mot pour la faire entrer dans une fiche de poste. Nommer une compétence crée la catégorie qui permet de la budgéter : sans le mot, même une compétence partiellement mesurable (les points de validation d’une chaîne d’agents en sont un exemple concret) ne peut pas entrer facilement dans une fiche de poste.

Or la compétence se forme dans la pratique, et non dans le catalogue de formation. Mesurer qu’une chaîne d’agents produit du juste plutôt que du plausible est une compétence à part entière, pas uniquement une case cochée dans une définition de fonction. Ce travail ne s’enseigne pas en atelier d’une journée, et ne se transmet pas mieux par la veille seule (la veille nourrit la reconnaissance, la pratique construit la compétence). Il se construit sur des dizaines d’itérations, avec des critères qui échouent avant de tenir. Et les formations ont l’avantage d’accélérer les prises de conscience et d’aider à monter la première marche.

Illustration du déficit de compétences IA en entreprise

Étage 2 : le recrutement demande actuellement ce qu’il a du mal à nommer

Le même mécanisme se rejoue sur les fiches de poste. Le RAG est demandé huit fois plus souvent que l’évaluation, alors que l’évaluation figure dans la définition même du métier d’AI Engineer. AI Shipping Labs ↗ montre qu’un titre unique recouvre en réalité trois populations distinctes :

  • environ 70 % de profils « AI-first »,

  • 28,5 % de profils « AI-support »,

  • et moins de 2 % de machine learning classique.

Le brouillard n’est pas subi par le recruteur, il contribue à le fabriquer.

Le brouillard n’est pas subi par le recruteur, il contribue à le fabriquer. Une fiche de poste qui liste RAG, fine-tuning et intégration LLM (grand modèle de langage) décrit des compétences visibles, démontrables en entretien technique, comparables entre candidats. Une fiche qui demanderait « sait juger si un système d’IA fait ce qu’il prétend faire » n’a pas, aujourd’hui de format d’entretien établi, pas de test standardisé, pas de case à cocher dans un ATS (le logiciel de suivi des candidatures). Le recruteur ne demande pas ce dont il a réellement besoin sur ces périmètres de recrutement. Il demande ce qu’il sait évaluer, d’autant plus qu’il n’est pas lui-même expert de ces métiers et qu’en se positionnant en HRBP (Human Resource Business Partner - partenaire métier), il se fait souvent écho des propres limites de son interlocuteur à formaliser ce dont il a vraiment besoin sur le terrain. Un peu comme toutes ces candidatures où l’on ajoute l’anglais comme compétence attendue, alors que tout le monde travaille en français dans l’organisation d’accueil. Le même flou touche déjà l’entrée dans le métier : si l’IA fait le travail des juniors, par où entre-t-on dans le métier ?

Étage 3 : le pilotage suit la courbe qui bouge

Un COMEX (comité exécutif) qui suit ses indicateurs d’adoption regarde une courbe qui monte : l’usage individuel de l’IA progresse vite, parce qu’il se mesure facilement (nombre de licences, fréquence d’usage déclarée, nombre de tokens consommés, factures afférentes…). Il ignore la courbe qui ne bouge pas : la mise en production stagne, parce que ce qui la bloque n’a pas d’indicateur associé, le même écart entre ce qui se mesure facilement et ce qui compte réellement que celui décrit dans l’IA accélère le code, et ralentit les développeurs.

Près de 88 % des pilotes n’aboutissent pas. Le blocage n°1, cité par 64 % des dirigeants, est l’évaluation ; viennent ensuite la gouvernance (57 %) et la fiabilité (51 %). Un dirigeant qui budgète une formation prompting pour ses équipes pendant que ses pilotes meurent faute d’évaluation subit une asymétrie d’instrumentation : le nombre de licences ou la fréquence d’usage sont des mesures qui existent déjà, prêtes à l’emploi. Le taux d’échec d’un pilote faute d’évaluation, lui, n’a pas d’instrument par défaut : il faut construire la mesure avant de pouvoir la suivre. Un COMEX pilote ce qui s’affiche déjà, pas ce qui exigerait de créer l’affichage. J’ai bien conscience de forcer le trait ici pour accompagner l’analyse, mais je rebondis sur des études aux protocoles variés dans l’optique d’esquisser un cap, la malédiction des PoC documente le même aveuglement organisationnel à l’échelle du pilote plutôt que de la compétence.

Ce que déplace le fait de nommer

Mon hypothèse est qu’il s’agit d’un déficit de vocabulaire. Et cela change la nature du problème puisque cela devient un sujet de définition de fonctions. Pour recruter on nomme la fonction à l’intérieur du poste, pour qu’elle devienne quelque chose qu’un recruteur peut demander, qu’un manager peut évaluer. Or le vocabulaire se stabilise à peine et les métiers avec lui. Les LLM courants reformulent nos prompts pour nous, embarquant avec eux le métier de prompt engineer. L’IA agentique, elle, a atteint un autre niveau de maturité depuis le début de l’année : le périmètre même de ce qu’on recrute se déplace plus vite que le vocabulaire pour le nommer. Andrej Karpathy, l’inventeur du terme vibe coding maintenant chez Anthropic, dit qu’il n’a plus écrit une ligne de code depuis décembre alors que cela représentait encore 20 % de son travail un an plus tôt.

Un consultant qui vend de l’accompagnement IA applique le même mécanisme qu’à l’étage 1 : sans le mot pour nommer l’évaluation comme mission, il n’y a pas de ligne de facturation pour la vendre séparément du reste. Elle se dilue dans un forfait générique, invendable au tarif qu’elle mériterait si elle était nommée. Un manager, lui, hérite du brouillard fabriqué à l’étage 2 : il recrute sur des intitulés qu’il n’a pas les moyens de challenger, parce que le marché ne lui en propose pas d’autres, et se retrouve à arbitrer entre candidats sur des critères qui ne mesurent pas ce qui bloquera la production. Le pair technique et l’étudiant subissent la même dynamique par ricochet : l’un fait le travail sans ligne budgétaire dédiée, l’autre se forme sur ce qui se vend plutôt que sur ce qui décide. C’est le même décalage qui rend la GPEC classique inopérante face à l’accélération : on planifie des métiers dont le périmètre bouge plus vite que le cycle de planification.

Ce qui bloque n’a pas de nom. Tant que cela reste vrai, ça continuera de ne pas être budgété.

Ce que j’en retiens

  • AI Shipping Labs, l’APEC et les données de production 2026 documentent chacune un symptôme isolé. Mis côte à côte, ils dessinent un seul mécanisme observé à trois échelles.
  • Nommer une compétence n’est pas un exercice sémantique mais la condition pour qu’elle devienne finançable, recrutable, pilotable.
  • La réponse ne tient pas dans cet article. Elle tient dans le vocabulaire qu’on se donne pour désigner ce qui, aujourd’hui, reste innommé dans nos organisations.
  • En conclusion, cet article pose un diagnostic : les intitulés actuels de compétences sur le périmètre de l’IA se concentrent sur des compétences évaluables, alors que la compétence à évaluer la pertinence d’un dispositif (ou d’un système agentique) en production, premier facteur d’échec de passage à l’échelle des initiatives actuelles, est rarement dans la fiche de poste (~4% des cas). Les volets 2 et 3 de cette série proposent une grille plus fine, comme tentative pour aider les managers à mieux constituer leurs équipes IA.

Les opinions exprimées ici sont personnelles et n'engagent pas mon employeur.