Le titre ‘ingénieur en IA’ est trop vague. Il ne tient pas compte des différences cruciales entre les compétences techniques nécessaires pour prototyper rapidement des solutions, les mettre en production ou concevoir l’infrastructure pour les déployer à grande échelle. Pourtant, c’est précisément ce que recherchent de nombreuses entreprises aujourd’hui.

Le problème des évaluations traditionnelles

La plupart des tests techniques actuels datent d’une époque pré-IA. Ils évaluent la maîtrise du code, des algorithmes et de la conception de systèmes déterministes. Or, ces compétences ne suffisent plus pour les rôles en IA. Elles ne révèlent pas si un ingénieur possède le ‘goût technique’ nécessaire pour prendre les bonnes décisions lors de la mise en production, de l’échelle ou du déploiement des systèmes d’IA.

Prenons un exemple concret : une entreprise recherche un expert en plateforme de données spécifique. Un candidat réussit l’évaluation technique, mais lors de l’entretien client, il est incapable d’expliquer pourquoi une approche serait bien meilleure qu’une autre dans un contexte donné. Résultat : il est écarté.

Les limites des années d’expérience

Exiger ‘5 ans d’expérience en IA’ dans les offres d’emploi est contre-productif. Ce domaine étant récent, cette exigence écarte des candidats compétents. Ce qui compte, c’est la profondeur et la spécificité de ce qu’ils ont construit, déployé ou mis à l’échelle en production.

Le paradoxe des évaluations

Lorsque les parties prenantes se plaignent simultanément que les tests sont trop difficiles et trop faciles, cela indique un problème fondamental. Les évaluations ne mesurent pas les bons critères. Elles testent des compétences techniques plutôt que le ‘goût technique’ nécessaire pour prendre des décisions architecturales judicieuses.

Une solution : décomposer le besoin

Pour combler ce fossé, il faut décomposer le problème avant d’évaluer les candidats. Identifier les dimensions clés : le domaine technique, le niveau de maturité requis et le pattern d’engagement avec les systèmes d’IA. Par exemple, un prototyper a besoin de sentir la valeur, tandis qu’un ‘builder’ doit maîtriser l’architecture et les décisions d’intégration.

Cette approche remplace la description de poste unique par une vision structurée des besoins réels. Elle révèle souvent qu’une seule personne ne suffit pas et qu’une équipe aux profils complémentaires est nécessaire.