Lire une offre IA : repérer le périmètre réel derrière l'intitulé

Ce qu'une annonce dit, et ce qu'elle laisse deviner

Une annonce est un document de compromis. Elle est écrite à plusieurs mains — une équipe technique, un recrutement, parfois une direction — et elle mélange ce que l'entreprise cherche vraiment, ce qu'elle croit devoir écrire, et ce qu'elle a copié d'une annonce précédente. La lire littéralement conduit à deux erreurs symétriques : postuler à des postes qui ne correspondent pas, ou renoncer à des postes qui correspondaient.

L'objectif n'est donc pas de vérifier si vous cochez les cases, mais de reconstituer le poste réel : quel problème l'entreprise veut faire disparaître, quelle responsabilité elle confie, et dans quel environnement le travail se fera.

Ce guide répond à une seule question : « cette opportunité correspond-elle réellement à mon profil et à ce que je cherche ? » La manière de présenter ensuite votre expérience est traitée dans le guide consacré à l'adaptation du CV.

Le titre, puis la mission réelle

Commencez par ignorer le titre. Lisez d'abord le paragraphe qui décrit le quotidien du poste et les responsabilités : c'est presque toujours la partie la moins retouchée, donc la plus fiable. Le titre, lui, dépend de la grille interne de l'entreprise autant que du contenu du poste.

Trois questions permettent de reconstituer la mission :

• Quel problème la personne recrutée doit-elle faire disparaître ? Un système qui n'existe pas, un système qui existe mal, ou une équipe qui n'arrive pas à livrer ?
• Quel serait un succès visible au bout de six mois, du point de vue de l'entreprise ?
• Le poste est-il créé, remplacé, ou ouvert après une tentative précédente ?

Si le texte ne permet de répondre à aucune des trois, ce n'est pas nécessairement disqualifiant — mais cela devient la première chose à demander en entretien.

Responsabilités réelles et niveau d'autonomie

Deux postes au même intitulé peuvent confier des responsabilités opposées. Le vocabulaire de l'annonce trahit souvent le niveau d'autonomie attendu : « contribuer à », « participer à » et « accompagner » ne décrivent pas la même chose que « définir », « arbitrer » ou « être garant de ».

• Autonomie forte : vous choisissez l'approche, vous défendez des arbitrages, vous portez la responsabilité du résultat.
• Autonomie encadrée : l'architecture est posée, vous décidez à l'intérieur d'un cadre existant.
• Autonomie faible : les choix sont faits ailleurs et vous les mettez en œuvre.

Aucun des trois n'est mauvais en soi ; ils ne conviennent simplement pas aux mêmes moments d'une trajectoire. Le problème apparaît quand l'annonce promet le premier et que l'organisation décrite correspond au troisième.

Compétences indispensables, souhaitables, et catalogues

La plupart des annonces mélangent trois listes : ce qui est réellement indispensable, ce qui serait confortable, et ce qui a été ajouté par précaution. Une stack longue de vingt technologies n'est pas un cahier des charges, c'est une liste de tout ce que l'équipe utilise, y compris ce que personne ne touchera dans les six premiers mois.

• Signal utile : quelques technologies nommées avec leur usage — « base vectorielle pour la recherche documentaire », « orchestration de traitements batch ».
• Signal faible : une énumération sans contexte, où figurent à la fois des frameworks concurrents et des outils appartenant à des métiers différents.
• Signal d'alerte : une annonce qui demande une expertise avancée sur un ensemble d'outils qu'aucune personne seule ne pratique quotidiennement.

Concentrez votre lecture sur ce qui apparaît dans la description des missions, pas seulement dans la liste des compétences. Ce qui revient dans les deux est réellement attendu.

AI Engineer, ML Engineer, Data Scientist, GenAI Engineer

Ces intitulés se recouvrent, et beaucoup d'annonces les emploient de manière interchangeable. Plutôt que de chercher la bonne définition, cherchez l'objet du travail décrit dans le texte.

• Le travail porte sur des modèles existants intégrés dans un produit — appels, contexte, récupération d'information, évaluation, fiabilité en production : c'est une orientation AI Engineer, quel que soit le titre.
• Le travail porte sur l'entraînement, la validation, le réentraînement, la donnée d'apprentissage et le déploiement de modèles internes : orientation ML Engineer.
• Le travail porte sur l'analyse, la modélisation statistique, l'expérimentation et la restitution de résultats à des décideurs : orientation Data Scientist.
• Le travail porte spécifiquement sur des systèmes génératifs — assistants, RAG, agents, prompts industrialisés : orientation GenAI, souvent proche de l'AI Engineer avec un accent produit.

Quand l'annonce mélange les quatre, ce n'est pas toujours de la confusion : c'est parfois le signe d'une petite équipe où une seule personne couvre plusieurs rôles. Reste à savoir lequel occupera l'essentiel du temps, et cette question se pose en entretien.

Regardez enfin la place accordée au software engineering : tests, revue de code, CI, mise en production, astreinte. Sa présence indique un poste où le code part réellement en production ; son absence complète, dans un poste annoncé « en production », est une contradiction à éclaircir.

Expérimentation ou production, données et infrastructure

C'est la dimension la plus discriminante, et souvent la moins explicite. Un poste d'exploration et un poste d'industrialisation demandent des réflexes différents et laissent des traces différentes sur un parcours.

• Indices d'exploration : notebooks, preuves de concept, expérimentations, « évaluer la faisabilité », absence de mention d'utilisateurs finaux.
• Indices de production : SLA, monitoring, coûts, latence, volumétrie, incidents, versions de modèles, utilisateurs existants.
• Indices sur la donnée : existence d'un entrepôt ou d'une plateforme, équipe data séparée ou non, mention de qualité, de gouvernance ou de droits d'accès.
• Indices d'infrastructure : cloud nommé, orchestrateur, industrialisation déjà en place — ou rien du tout, ce qui signifie souvent que la construire fera partie du poste.

Lorsque les termes RAG, agents ou LLM apparaissent, cherchez ce qui les entoure. Une annonce qui mentionne l'évaluation, la qualité des réponses, la gestion des échecs ou la maîtrise des coûts décrit un système exploité. Une annonce qui n'en parle jamais décrit plus probablement une intention.

Séniorité, équipe et rattachement

La séniorité annoncée en années dit peu de chose ; le contexte, beaucoup. Un poste « senior » dans une équipe de quinze personnes avec un lead technique n'implique pas les mêmes attentes qu'un poste « senior » qui se révèle être le premier profil IA de l'entreprise.

• Taille et composition de l'équipe : y a-t-il déjà des profils IA, data, ou seulement des développeurs ?
• Rattachement : technologie, produit, métier, R&D — cela détermine à qui vous devrez expliquer vos arbitrages.
• Interlocuteurs cités : un lead technique, un product manager, une direction métier, un client final.
• Présence ou absence d'un cadre d'ingénierie : revue, tests, industrialisation, pratiques d'évaluation.

Une annonce qui décrit précisément l'équipe et son fonctionnement est déjà un signal de maturité : quelqu'un a pris le temps de réfléchir au poste avant de le publier.

Une méthode de lecture en cinq dimensions

Pour comparer plusieurs offres sans se perdre, classez chacune sur cinq axes, en une ligne chacun. L'exercice prend cinq minutes et rend les décisions beaucoup plus simples.

• Objet : produit, plateforme, exploration, ou support d'autres équipes.
• Maturité : premier projet IA, système en construction, système déjà en production.
• Responsabilité : exécution, décision encadrée, décision assumée.
• Technique dominante : intégration de modèles, entraînement, données, ingénierie logicielle.
• Conditions : localisation, rythme, organisation, contraintes explicites.

Une offre qui reste illisible sur trois axes ou plus n'est pas forcément mauvaise, mais elle vous demandera un entretien exploratoire avant toute candidature préparée.

Décoder un extrait d'annonce

Voici un extrait fictif, proche de ce que l'on rencontre couramment. La colonne de droite montre ce qu'il faut en retenir.

Signaux d'une annonce vague ou contradictoire

• Aucune mention d'un problème concret, seulement des technologies et des ambitions.
• Un poste unique censé couvrir recherche, ingénierie de données, production et relation client.
• Des attentes de production sans aucune mention d'infrastructure, de tests ou de qualité.
• Une séniorité élevée exigée avec un périmètre décrit comme purement exécutant.
• Une liste de compétences plus longue que la description des missions.
• Un vocabulaire à la mode utilisé sans objet : des « agents » sans cas d'usage, une « IA générative » sans utilisateur identifié.

Un ou deux de ces signaux appellent des questions. Quatre ou cinq indiquent que l'entreprise n'a pas encore défini le poste — ce qui peut être une opportunité si vous cherchez à le définir vous-même, et un piège dans le cas contraire.

Faut-il cocher toutes les cases ?

Non, et attendre de tout cocher revient à ne candidater qu'à des postes en retrait de son niveau. La bonne lecture consiste à séparer ce qui est structurant de ce qui s'apprend.

• Structurant : le type de travail attendu, le niveau de responsabilité, le rapport à la production, le domaine si l'annonce l'exige explicitement.
• Apprenable : un outil précis, un cloud particulier, un framework d'orchestration, une base vectorielle donnée.
• Négociable en entretien : la séniorité affichée, une partie du périmètre, l'organisation du travail.

Si le cœur du poste correspond à ce que vous savez démontrer et que les écarts portent sur des outils, candidatez. Si l'écart porte sur la nature même du travail — de l'exploration alors que vous cherchez de la production, ou l'inverse — l'annonce vous a rendu service en vous l'indiquant avant l'entretien.

Une lecture méthodique fait gagner du temps des deux côtés : elle réduit les candidatures inadaptées et rend les entretiens beaucoup plus précis.

• Recherche d'emploi
• AI Engineering