Le vrai problème n'est pas le manque de compétences
Une part importante des professionnels qui hésitent à parler d'IA sur leur CV ont pourtant fait quelque chose de réel : ils ont identifié un cas d'usage, testé un outil sur des données de leur métier, écrit des critères d'acceptation, animé un pilote, ou expliqué à une équipe pourquoi une réponse générée ne devait pas être envoyée telle quelle. Ce travail existe. Il est simplement décrit d'une façon qui le rend invisible.
Le sujet de ce guide n'est donc pas de faire croire à une expertise. C'est exactement l'inverse : rendre visible et vérifiable une contribution réelle, en la formulant avec la précision qu'on emploierait pour n'importe quelle autre partie de son métier.
Un recruteur ou un manager technique ne cherche pas à savoir si vous connaissez le vocabulaire. Il cherche à savoir ce que vous avez fait, dans quelles conditions, et ce qui reste vrai quand on retire l'enthousiasme.
Sept niveaux d'expérience qu'il faut cesser de confondre
« Compétences IA » recouvre des réalités très inégales. Les distinguer permet de se situer honnêtement — et d'éviter aussi bien la sous-estimation que la surpromesse.
- Avoir utilisé un assistant conversationnel : usage individuel, sans effet organisationnel démontrable. C'est un point de départ, pas une compétence à revendiquer seule.
- Avoir automatisé un traitement ou un enchaînement de tâches : un résultat concret existe, mais son ampleur et sa robustesse déterminent ce qu'on peut en dire.
- Avoir cadré un cas d'usage : problème, utilisateurs, périmètre, données, risques, critères. C'est une compétence professionnelle transférable, et elle est rare.
- Avoir contribué à un produit intégrant une brique IA : spécification, arbitrages, suivi, participation aux décisions produit.
- Avoir défini ou testé des critères d'évaluation : jeu de cas, ce qu'est une bonne réponse, seuils, revue de sorties. C'est souvent la contribution la plus recherchée et la moins revendiquée.
- Avoir participé à l'adoption ou à la gouvernance : règles d'usage, formation, cadre de conformité, suivi des usages réels.
- Avoir travaillé avec une équipe Data ou AI Engineering : collaboration régulière, langage commun, décisions partagées, sans se substituer aux ingénieurs.
Ces niveaux ne forment pas une échelle de valeur linéaire : cadrer un cas d'usage difficile vaut souvent plus, sur un poste produit ou conseil, que d'avoir bricolé une automatisation. Ils forment surtout une grille de précision. Dire lequel vous occupez réellement est déjà un signal de sérieux.
Passer d'une formulation faible à une formulation démontrable
La méthode tient en six éléments. Une bonne formulation ne les contient pas tous à chaque fois, mais une formulation faible n'en contient généralement aucun.
- 1
Le contexte
Où, avec qui, dans quelles contraintes. « Dans une direction juridique de quinze personnes, sur des documents contractuels non structurés » situe immédiatement le niveau de difficulté.
- 2
Le problème
Ce qui ne fonctionnait pas avant, exprimé du point de vue du travail réel : temps perdu, décisions retardées, information introuvable, tâche répétitive à faible valeur.
- 3
Votre responsabilité personnelle
Ce que vous avez fait, vous, distinct de ce que l'équipe a fait. C'est le point le plus souvent flou, et celui qui est systématiquement creusé en entretien.
- 4
L'approche
Comment vous vous y êtes pris : cadrage, collecte de cas réels, définition de critères, tests, pilote, accompagnement. Décrire la démarche, pas la technologie.
- 5
Le résultat
Ce qui a changé, de manière observable. Un résultat modeste et vérifiable vaut mieux qu'un pourcentage impressionnant que vous ne pourrez pas justifier.
- 6
Les limites
Ce que la solution ne couvrait pas, ce qui a été abandonné, ce qui reste ouvert. C'est ce qui distingue quelqu'un qui a réellement travaillé sur le sujet de quelqu'un qui l'a lu.
Si vous n'avez pas de chiffre fiable, n'en inventez pas. « Le temps de préparation a nettement diminué, sans que nous l'ayons mesuré formellement » est une phrase acceptable, et personne ne peut la retourner contre vous.
Trois exemples avant / après
Les formulations « avant » ci-dessous sont volontairement typiques : elles apparaissent telles quelles sur beaucoup de CV. Les situations décrites sont des scénarios pédagogiques, à adapter à votre expérience réelle.
Product / Product Owner
Avant
« Pilotage d'un projet IA. Utilisation de ChatGPT et d'outils IA au quotidien. »
Après
« Sur une fonctionnalité d'assistance à la rédaction destinée à une équipe support de trente personnes, j'ai cadré le périmètre avec l'équipe technique : trois types de demandes traitées, sources autorisées, comportement attendu en cas de doute (proposer un modèle vide plutôt qu'une réponse incertaine) et interdiction de tout engagement commercial dans la proposition. J'ai constitué le jeu de quatre-vingts cas réels anonymisés utilisé pour valider les versions. La fonctionnalité est utilisée quotidiennement sur le périmètre restreint ; l'extension aux demandes complexes a été écartée après les tests, faute de sources fiables. »
Business Analyst / consultant
Avant
« Expertise IA générative. Accompagnement de la transformation IA du client. »
Après
« Pour une direction financière, j'ai instruit quatre cas d'usage candidats et recommandé de n'en retenir qu'un. Pour chacun, j'ai documenté les données réellement disponibles, les droits d'accès, la fréquence de mise à jour et la conséquence d'une erreur. Deux cas ont été écartés parce que les données n'étaient pas exploitables en l'état, un troisième parce que le gain attendu ne justifiait pas la charge de contrôle. Le cas retenu a été spécifié avec des critères d'acceptation évaluables, testés sur des dossiers réels avec les équipes métier. »
UX / projet & transformation
Avant
« Conception d'expériences IA. Sensibilisation des équipes aux outils IA. »
Après
« J'ai mené huit entretiens avec des utilisateurs d'un assistant interne pour comprendre pourquoi l'usage retombait après deux semaines. Le problème n'était pas la qualité des réponses mais l'absence de moyen de vérifier leur origine. J'ai conçu et testé une présentation des sources et un mécanisme de signalement, puis défini avec l'équipe produit ce que le système devait faire lorsqu'il n'était pas sûr. J'ai également écrit les règles d'usage diffusées aux équipes, en distinguant les tâches où la relecture humaine restait obligatoire. »
Dans les trois cas, la version « après » ne revendique aucune compétence technique. Elle est pourtant beaucoup plus difficile à écrire pour quelqu'un qui n'aurait pas fait le travail — c'est précisément ce qui la rend crédible.
Adapter le message selon le support
Le fond reste le même ; le format et le niveau de détail changent.
CV
Deux à quatre lignes par expérience, orientées responsabilité et résultat. Pas de rubrique « compétences IA » listant des outils : une liste d'outils ne prouve rien et invite à des questions auxquelles vous ne voudrez pas répondre. Si vous tenez à une ligne de compétences, formulez-la par capacités : « cadrage de cas d'usage IA, définition de critères d'évaluation, conduite de pilote ».
Profil TalentAI
L'espace permet d'être plus précis que sur un CV : décrivez le type de problèmes que vous savez traiter, le contexte dans lequel vous intervenez et le niveau réel de votre pratique. Un profil qui dit clairement « je ne développe pas, je cadre, je teste et je fais adopter » est plus utile aux entreprises qu'un profil qui laisse planer un doute.
Profil professionnel public
Sur un profil public, l'enjeu est la cohérence entre le titre et le contenu. Un titre qui annonce une expertise technique et une expérience qui décrit du cadrage produisent une impression négative immédiate. Un titre honnête — votre métier, avec la mention de votre domaine d'intervention IA — supporte beaucoup mieux la lecture. Évitez aussi de reprendre à l'identique une formulation de mode : elle vieillit vite et vous rend interchangeable.
Entretien
C'est là que la précision paie. Préparez deux situations que vous pouvez raconter pendant cinq minutes avec des détails concrets : ce que vous avez découvert en cours de route, la décision difficile, ce qui a été abandonné. Préparez aussi la phrase qui délimite votre périmètre : « je n'ai pas conçu le système ; j'ai défini ce qu'il devait faire, avec quelles données, et comment nous vérifierions que c'était le cas ». Cette phrase clôt le sujet au lieu de l'ouvrir.
Portfolio ou cas pratique
Un portfolio n'est pertinent que si vous pouvez montrer quelque chose sans violer une confidentialité : un document de cadrage anonymisé et reconstruit, une grille de critères d'évaluation, un protocole de test, un retour d'expérience structuré. Ce n'est pas obligatoire pour un profil non technique, et un mauvais portfolio nuit plus qu'il n'aide. En revanche, un exercice de cadrage traité proprement lors d'un entretien remplace avantageusement n'importe quel document.
Ce qu'il vaut mieux ne pas revendiquer
Certaines formulations produisent l'effet inverse de celui recherché. Elles attirent des questions techniques précises, et l'écart se voit immédiatement.
- « AI Engineer » après quelques automatisations : le titre engage sur une pratique d'ingénierie que vous n'aurez pas à démontrer une fois, mais à chaque échange.
- « Expert LLM » après un usage régulier d'un assistant : l'expertise sur les modèles suppose de savoir en parler sous l'angle de l'évaluation, du coût et des limites, pas de l'usage.
- « Expert RAG » ou « spécialiste des agents » sans expérience démontrable : ce sont des sujets d'ingénierie ; les revendiquer sans avoir construit ni évalué expose à un démenti en une question.
- Une maîtrise technique invérifiable — outils cités sans contexte, technologies listées sans réalisation associée.
- Un résultat chiffré que vous ne pouvez pas expliquer : d'où vient le chiffre, comment il a été mesuré, sur quelle période.
- Une contribution collective présentée au singulier : c'est la faute la plus facilement détectée, et la plus coûteuse.
La règle qui simplifie tout : ne revendiquez rien que vous ne pourriez pas défendre pendant dix minutes face à quelqu'un qui pratique le sujet quotidiennement.
Assumer un positionnement non technique
Il existe une inquiétude légitime derrière ces hésitations : la crainte que sans compétence technique, la candidature ne pèse pas. Dans la pratique, les organisations qui déploient des systèmes IA manquent rarement de personnes capables de construire ; elles manquent de personnes capables de dire ce qu'il faut construire, pour qui, avec quelles données, et à quelles conditions le résultat sera acceptable.
Formuler clairement ce positionnement — ce que vous savez faire, ce que vous ne faites pas, et avec qui vous travaillez bien — est plus efficace que de gonfler un vernis technique. C'est aussi ce qui permet d'arriver dans une équipe sans avoir à tenir un rôle qu'on ne peut pas tenir.
Les preuves à rassembler
Avant de reformuler votre CV ou votre profil, réunissez ce que vous pourrez réellement montrer ou raconter en détail.
- Le contexte précis d'au moins deux situations : organisation, utilisateurs, contrainte principale.
- Ce que vous avez personnellement produit : document de cadrage, jeu de cas, critères, protocole de test, plan d'adoption.
- Les décisions auxquelles vous avez contribué, et celles que vous n'avez pas prises.
- Un ou deux exemples de cas limites que vous aviez identifiés.
- Le résultat observable, même modeste, et la façon dont il a été constaté.
- Ce qui n'a pas fonctionné, et ce que vous en avez tiré.
- Les personnes avec qui vous avez travaillé et ce qu'elles pourraient confirmer.
- Ce que vous ne savez pas faire, formulé sans gêne.
À retenir
- L'objectif n'est pas de paraître expert, mais de rendre vérifiable ce que vous savez réellement faire.
- « Utiliser un assistant » et « cadrer un cas d'usage » sont deux niveaux d'expérience très différents : il faut les nommer séparément.
- Une formulation solide contient contexte, problème, responsabilité personnelle, approche, résultat et limites.
- Dire ce qui n'a pas marché renforce la crédibilité au lieu de l'affaiblir.
- Les intitulés techniques non démontrables — AI Engineer, expert LLM, expert RAG — se retournent contre celui qui les emploie.
- Les preuves se rassemblent avant l'entretien : cas, critères, documents, décisions, retours d'utilisateurs.
- Culture IA
- AI Product
- Adoption