GenAI Engineer, AI Product, Architecte IA : des rôles encore en cours de définition

Depuis l'arrivée des modèles génératifs dans les organisations, les intitulés se multiplient : AI Engineer, GenAI Engineer, AI Product Manager, AI Solutions Architect, AI Quality Lead, Conversation Designer, AI Adoption Lead. Cette prolifération est réelle, mais elle est plus difficile à lire qu'il n'y paraît, parce qu'un nouvel intitulé peut recouvrir plusieurs situations très différentes.

Titre, responsabilité, métier : trois choses différentes

L'arrivée de la GenAI produit au moins cinq effets distincts, souvent confondus sous le même mot de « nouveau métier ». Elle peut créer des responsabilités qui n'existaient pas, renforcer une spécialisation déjà présente, déplacer la frontière entre deux rôles existants, produire un intitulé neuf sans changer le travail, ou simplement ajouter une composante GenAI à un poste inchangé par ailleurs.

Six familles de responsabilités qui se dessinent

Ce découpage n'est pas une nomenclature. C'est une grille de lecture : dans une organisation donnée, ces familles peuvent correspondre à six postes distincts, à deux postes, ou à une seule personne qui les porte toutes avec un titre quelconque.

AI / GenAI Engineer

Construire des applications autour de modèles : intégration d'API, recherche documentaire, workflows et agents, évaluation, exploitation en production. Le recouvrement avec le software engineering est important — c'est d'abord de l'ingénierie logicielle — et le recouvrement avec le ML engineering dépend de la présence, ou non, de modèles entraînés en interne. Deux offres portant ce titre peuvent décrire l'une un travail d'intégration applicative, l'autre un travail proche de la plateforme.

AI Product

Product manager ou product owner avec des responsabilités spécifiques liées au comportement probabiliste : définir ce qu'est une réponse acceptable, organiser l'évaluation, arbitrer entre qualité, coût et latence, traiter la question des données et du risque, mener une discovery de cas d'usage dans laquelle la faisabilité n'est jamais acquise. La compétence produit reste centrale ; ce qui change, ce sont les critères de décision.

AI Solutions et architecture

Traduire un besoin en architecture exploitable dans un contexte d'entreprise : intégration au système d'information, sécurité et droits d'accès, provenance et cycle de vie des données, choix entre construire et acheter, contraintes réglementaires et contractuelles. Ce rôle existait avant la GenAI ; ce qui est nouveau, ce sont les arbitrages spécifiques que ces systèmes imposent.

Évaluation et qualité IA

Constituer des jeux de cas représentatifs, définir des critères d'acceptation, détecter les régressions, caractériser les comportements indésirables, rendre la qualité observable dans le temps. Dans certaines organisations, c'est un rôle dédié. Dans beaucoup d'autres, c'est une responsabilité répartie entre l'ingénierie, le produit et les équipes métier — et la question intéressante, en entretien, est de savoir laquelle des deux situations vous rejoignez.

Conversation et AI UX

Concevoir l'interaction avec un système dont la sortie n'est pas garantie : formulation des attentes, gestion de l'incertitude et de l'erreur, mécanismes de repli, intervention humaine, construction de la confiance, compréhension de ce que les utilisateurs font réellement du système. Aucun titre unique ne s'impose ici, et la responsabilité est souvent partagée avec le design produit existant.

Adoption et transformation

Accompagner les usages : processus concernés, compétences à construire, conduite du changement, règles d'usage, gouvernance opérationnelle. C'est la famille la plus éloignée de la technique et la plus dépendante du contexte organisationnel. Elle est aussi celle où l'intitulé varie le plus, du chef de projet au responsable de programme.

Lire une offre dont l'intitulé est nouveau

Face à un titre inconnu, la bonne question n'est pas « comment s'appelle ce poste » mais « qu'est-ce qui est réellement attendu ». Huit questions suffisent le plus souvent à reconstituer le travail derrière le titre.

• Quel problème dois-je résoudre, et pour qui dans l'organisation ?
• Qu'est-ce que je dois livrer concrètement : un prototype, un service en production, un cadre, une décision ?
• Quelles décisions m'appartiennent, et lesquelles restent ailleurs ?
• Quel niveau de code est attendu : écriture quotidienne, relecture, spécification, aucun ?
• Avec quelles équipes vais-je travailler au quotidien, et à quel rythme ?
• Qui possède les données dont dépend le système, et à quelles conditions y accède-t-on ?
• Qui évalue la qualité, et selon quels critères déjà existants ?
• Qui porte la production et l'astreinte, si le système est exploité ?

Les réponses à ces questions se recoupent d'un poste à l'autre bien mieux que les intitulés. Deux offres au titre identique peuvent y répondre de façon opposée ; deux offres aux titres différents peuvent décrire le même travail.

Ce que ce mouvement ne permet pas de conclure

La multiplication des intitulés est un fait observable. Ce qu'on en déduit souvent ne l'est pas. Trois précautions valent la peine d'être tenues.

• Un intitulé récent n'est pas un métier stabilisé : il peut disparaître, fusionner avec un autre ou changer de contenu sans prévenir.
• Un intitulé fréquent dans les offres n'est pas un standard : les organisations copient les formulations qu'elles voient ailleurs, y compris quand elles décrivent autre chose.
• Une responsabilité nouvelle n'implique pas un poste nouveau : elle est souvent absorbée par un rôle existant, ce qui est le cas le plus fréquent dans les équipes de taille modeste.

Le cas du Prompt Engineer illustre bien la difficulté. Le terme a désigné, selon les moments et les organisations, une compétence transversale attendue de tout le monde, une spécialisation réelle sur des systèmes complexes, et un intitulé de poste autonome. Ces trois lectures ne sont pas équivalentes, et aucune ne constitue une trajectoire professionnelle universelle.

Se situer sans attendre une nomenclature stable

Il n'y aura probablement pas de moment où le vocabulaire se fixe et où chacun saura enfin comment s'appeler. La stratégie praticable consiste donc à se décrire par ce qui est comparable d'une organisation à l'autre : les problèmes traités, les livrables, le niveau de responsabilité, l'environnement.

• Décrivez votre travail par les responsabilités que vous portez, en gardant le titre comme information secondaire.
• Quand vous postulez, alignez-vous sur le vocabulaire de l'offre sans adopter un titre que vous n'avez pas exercé.
• Vérifiez, en entretien, laquelle des six familles ci-dessus le poste recouvre réellement, et lesquelles sont portées par d'autres.
• Traitez un titre inhabituel comme une question à poser, pas comme un signal de sérieux ou d'amateurisme.

C'est aussi une protection : un professionnel qui sait décrire ses responsabilités reste lisible quand le vocabulaire change, alors qu'un professionnel identifié à un intitulé dépend de la durée de vie de cet intitulé.

• Marché
• Rôles GenAI
• Lecture d'offre