Avant de recruter un ingénieur IA, écrivez ce que l’outil devra faire

IA en production · 6 min

Le scénario est presque toujours le même. La direction a décidé qu’il fallait « faire de l’IA ». Quelqu’un rédige une annonce intitulée « ingénieur IA », avec une liste de compétences reprise de plusieurs annonces trouvées en ligne : des langages, des outils, des noms de modèles. Les candidatures arrivent, nombreuses. Les entretiens techniques sont menés par une personne de la DSI qui connaît bien le développement, mais pas le problème métier à résoudre. On retient le profil le plus solide sur le papier.

Quelques mois plus tard, la personne recrutée est compétente, motivée, et elle cherche encore ce qu’on attend d’elle. Elle a construit une démonstration qui impressionne en réunion. Personne ne sait dire si elle est juste, sur quels documents elle a été testée, ni qui doit la valider. La direction métier qui portait le besoin a décroché.

Le problème n’est pas le candidat. C’est qu’on a recruté avant d’avoir écrit ce que l’outil devait faire.

Un ingénieur IA n’est pas un développeur de plus

Derrière l’intitulé « ingénieur IA », il y a des métiers très différents. Certains savent entraîner et évaluer des modèles statistiques. D’autres savent brancher un service d’IA existant sur vos documents, vos règles et vos outils, puis le surveiller une fois en service. D’autres encore savent industrialiser : sécurité, hébergement, intégration au système d’information. Un même projet n’a presque jamais besoin des trois au même moment.

Quand le besoin n’est pas écrit, le recrutement se fait sur ce qui se voit : un diplôme, un nom d’entreprise, une liste d’outils. On choisit le profil le plus impressionnant au lieu du profil adapté. Et on découvre l’écart une fois la personne en poste, au moment où il coûte le plus cher à corriger.

Je viens des achats. On n’y lance pas une consultation sans cahier des charges, parce qu’on sait qu’on ne pourra pas comparer les offres ni juger la prestation. Un recrutement IA obéit à la même logique : sans expression du besoin, on ne peut ni évaluer les candidats, ni savoir plus tard si le travail est réussi.

Les signaux d’alerte dans votre annonce

Relisez votre projet d’annonce. Si vous reconnaissez plusieurs de ces points, le cahier des charges manque :

l’annonce décrit des outils et des technologies, mais aucun document, aucune décision, aucun processus de votre organisation ;
le mot « IA » remplace la description du problème ;
personne côté métier n’a relu l’annonce ni ne participera aux entretiens ;
vous ne savez pas dire à quoi ressemblera un bon travail à la fin de la période d’essai ;
les missions mélangent recherche, développement, gestion de projet et formation des équipes ;
aucune ligne ne parle de ce que l’outil ne doit jamais faire, ni de la façon dont on vérifiera ce qu’il produit.

Ce dernier point est celui que je vois manquer le plus souvent. Il est pourtant décisif : un outil d’IA qui produit des documents ou prépare des décisions doit être contrôlé, et la personne que vous recrutez doit savoir construire ces contrôles.

Ce qu’il faut écrire avant de publier l’annonce

Un cahier des charges utile tient en quelques pages. Il ne décrit pas une solution technique ; il décrit le problème, les règles et ce qui comptera comme une réussite. Voici ce qu’il doit contenir.

Le problème qui coûte cher. Pas un « cas d’usage IA », un problème que vous savez décrire : une analyse de candidatures qui mobilise une équipe pendant chaque consultation, des rapports que quelqu’un relit chiffre par chiffre, des demandes clients qui se perdent. Écrivez ce qui se passe aujourd’hui, qui le fait, et ce que coûte une erreur.

Les documents concernés. Quels documents entrent, quels documents sortent, sous quelle forme. Rassemblez des exemples réels, y compris les dossiers difficiles : incomplets, mal scannés, contradictoires. Ce sont eux qui serviront à tester les candidats, puis l’outil.

Ce que l’outil doit faire, et ce qu’il ne doit jamais faire. La seconde liste est souvent plus importante que la première. Par exemple : ne jamais inventer un montant absent du document, ne jamais trancher seul une exclusion de candidat, ne jamais envoyer un message sans validation.

Les contrôles. Quelles règles métier doivent être vérifiées automatiquement, par un programme et non par l’IA elle-même : un total qui doit se recouper, une pièce obligatoire, une date qui doit correspondre. Ma règle de travail tient en une phrase : un document, un contrôle, une preuve. Chaque information produite doit renvoyer au document dont elle vient.

Les critères de réussite. Comment saurez-vous que l’outil fonctionne ? La réponse doit être mesurable sur vos propres documents, et décidée avant de construire, pas après.

Qui valide quoi. Qui relit, qui tranche les cas ambigus, qui signe. L’IA prépare ; une personne de votre organisation décide.

Le profil qui en découle. C’est seulement à cette étape que vous pouvez écrire la fiche de poste. Elle découle des sections précédentes, au lieu de les précéder.

Ce que le cahier des charges change dans le recrutement

Avec ce document en main, l’annonce change de nature. Elle décrit un problème concret, ce qui attire des candidats qui ont envie de le résoudre plutôt que des collectionneurs d’outils.

Les entretiens changent aussi. Au lieu de questions générales sur des technologies, vous pouvez donner au candidat un vrai document anonymisé et lui demander comment il s’y prendrait. Quelques questions révèlent beaucoup :

Comment saurez-vous que l’outil se trompe, et sur quels documents le testerez-vous ?
Que doit faire l’outil quand une information manque ou n’est pas lisible ?
Quelles règles confieriez-vous à un programme plutôt qu’à l’IA, et pourquoi ?
Comment montrerez-vous à l’équipe métier d’où vient chaque information produite ?
Qu’est-ce qui vous ferait dire que ce projet ne devrait pas utiliser l’IA ?

Un bon candidat parle de vos documents, de vos erreurs possibles et de la façon de les attraper. Un candidat moins adapté parle surtout d’outils. Le cahier des charges vous donne enfin une grille pour faire la différence, et il permet au manager métier de participer à l’entretien avec des questions qu’il maîtrise.

Il change enfin l’intégration. La personne recrutée sait dès son arrivée ce qu’on attend d’elle, sur quels documents elle sera jugée, et avec qui elle travaille côté métier.

Et si le cahier des charges conclut qu’il ne faut pas recruter

Écrire le besoin avant de recruter a une conséquence que peu d’organisations anticipent : parfois, la conclusion est qu’un recrutement n’est pas la bonne réponse. Le problème peut être réglé par un outil existant correctement paramétré. Il peut demander un premier prototype sur vos documents réels avant de savoir quel profil embaucher. Il peut aussi relever d’une simple réorganisation du processus, sans IA du tout.

Ce n’est pas un échec du cadrage, c’est précisément son rôle. Mieux vaut le découvrir sur le papier qu’après une période d’essai.

Avant de publier, vérifiez ces points

Le problème est décrit en termes métier, avec ce que coûte une erreur.
Des documents réels, dont des cas difficiles, sont rassemblés.
La liste de ce que l’outil ne doit jamais faire est écrite.
Les règles à vérifier par un programme sont identifiées.
Les critères de réussite sont fixés avant la construction.
Le circuit de validation humaine est défini.
Un responsable métier relit l’annonce et participe aux entretiens.
La fiche de poste découle de tout ce qui précède.

C’est le travail que je fais en premier avec les organisations que j’accompagne : écrire ce cahier des charges, puis aider à recruter le profil qui en découle. Le document reste exploitable quelle que soit la suite, que le projet soit mené en interne, avec moi ou avec un autre prestataire.

Vous préparez un recrutement IA ? Si vous voulez confronter votre projet d’annonce à ces questions, prenons trente minutes pour en parler.