Recruter un profil IA : ce qu'il faut vraiment chercher
RecrutementCompétencesÉquipeMéthode2026-07-148 min
Les offres demandent des frameworks. Ce qui distingue vraiment un profil, c'est sa capacité à écarter un cas d'usage et à construire une mesure.
Ce que les offres demandent, et pourquoi c'est le mauvais critère
La plupart des annonces listent des outils : tel cadre applicatif, telle base vectorielle, tel fournisseur de modèle. Ces compétences s'acquièrent en quelques semaines et se périment aussi vite.
Ce qui ne s'acquiert pas en quelques semaines, c'est le jugement sur ce qu'il ne faut pas construire. C'est pourtant ce qui sépare un système en service d'un prototype abandonné.
Les quatre choses que je regarde
- A-t-il déjà mis quelque chose en service ? Pas livré : mis en service, avec des utilisateurs qui s'en servaient encore six mois plus tard. Faire préciser le chiffre d'usage.
- Sait-il construire une mesure ? Demander comment il s'y prendrait pour savoir si un système répond bien. Une réponse qui parle de jeu de tests métier et de jugement extérieur vaut mieux qu'une réponse qui cite des indicateurs académiques.
- A-t-il déjà dit non ? Faire raconter un cas d'usage qu'il a refusé, et pourquoi. Un profil qui n'a jamais rien écarté n'a jamais eu de jugement à exercer.
- Comprend-il le métier de quelqu'un d'autre ? Lui faire expliquer le travail réel d'un utilisateur d'un de ses projets. La précision de cette description prédit mieux la réussite que n'importe quelle compétence technique.
Le profil qui ne fonctionne pas
L'excellent technicien qui n'a jamais quitté son environnement. Il produira un système remarquable sur des données propres, et il découvrira au sixième mois que le corpus réel ne ressemble pas à ce qu'on lui avait décrit.
Ce n'est pas un défaut de niveau, c'est un défaut d'exposition. Il se corrige en quelques mois si la personne accepte d'aller voir le travail se faire, et pas du tout si elle considère que ce n'est pas son métier.
La question que je pose en fin d'entretien
« Racontez-moi un système que vous avez construit et qui n'est plus utilisé. Pourquoi ? » Une réponse honnête et analytique en dit plus que trois réussites racontées. Un candidat qui n'a que des réussites n'a rien exploité assez longtemps.
Faut-il un docteur ?
Non, et je le dis alors que j'en suis un. Le doctorat apporte une exigence de mesure et une lecture critique des publications, utiles, mais pas indispensables, et acquérables autrement.
Ce qui compte davantage, c'est d'avoir vu un système vivre dans la durée : encaisser un changement de modèle, absorber une évolution du corpus, être repris par quelqu'un d'autre. C'est ce que je développe dans soutenir une thèse et déployer en entreprise.
Les deux questions qui révèlent le plus
« Quel projet avez-vous arrêté, et pourquoi » et « comment sauriez-vous que ce système fonctionne » : ces deux questions départagent mieux que tout le reste de l'entretien. Elles portent sur des compétences non déclaratives.
La première teste la capacité à renoncer, qui est la part du travail la plus rentable et la moins visible. Un candidat qui n'a jamais arrêté un projet n'a jamais eu à arbitrer.
La seconde teste la capacité à construire une mesure sur une question mal définie. Une réponse utile décrit un jeu de cas, une réponse attendue et un seuil ; une réponse insuffisante parle de qualité en général. La méthode correspondante figure dans construire un jeu de tests en une journée.
Le profil qui ne fonctionne pas, décrit
Celui qui connaît tous les outils et n'a jamais mis un système entre les mains d'utilisateurs réels. Il est fréquent et il coûte cher.
Le symptôme est reconnaissable en entretien : le candidat parle d'architectures et de modèles, jamais de corpus, d'utilisateurs ou de périmètre. Interrogé sur un échec, il décrit une limite technique plutôt qu'un problème d'organisation.
Or la quasi-totalité des projets échoue pour des raisons non techniques : corpus désordonné, absence de propriétaire métier, résultat invérifiable. Le constat détaillé figure dans agents en entreprise : où s'arrêtent les projets.
Ce qu'il faut écrire dans l'offre à la place
Décrire le système à construire et le corpus sur lequel il portera, plutôt que la liste des technologies attendues. Cela attire des candidats différents et filtre mieux.
Une offre qui énumère des bibliothèques attire ceux qui les connaissent. Une offre qui décrit un corpus documentaire désordonné, des utilisateurs métier et une exigence de traçabilité attire ceux qui ont déjà traité ce genre de situation.
Elle a un second mérite : elle oblige l'organisation à formuler ce qu'elle cherche réellement, ce qui révèle parfois que le besoin relève de la gestion documentaire plus que de l'IA, le point développé dans le corpus est le projet.
Questions fréquentes
- Quelles questions poser en entretien ?
« Quel projet avez-vous arrêté, et pourquoi » et « comment sauriez-vous que ce système fonctionne ». Elles testent la capacité à renoncer et à construire une mesure, qui ne se déclarent pas.
- Quel profil ne fonctionne pas ?
Celui qui connaît tous les outils sans avoir jamais mis un système entre les mains d'utilisateurs réels. Il parle d'architectures et jamais de corpus, d'utilisateurs ou de périmètre.
- Faut-il un docteur ?
Non. Ce qui compte est la capacité à écarter un cas d'usage et à construire une mesure, et aucun diplôme ne les prédit. Un excellent ingénieur peut les posséder, un docteur peut ne pas les avoir.
- Que faut-il écrire dans l'offre ?
Le système à construire et le corpus concerné, plutôt qu'une liste de technologies. Cela attire ceux qui ont déjà traité ce type de situation et oblige à formuler le besoin réel.