Ingénieur IA : compétences clés et questions pour le recruter

Depuis que les outils d'IA écrivent le code, produire des lignes n'est plus la partie difficile : le dur s'est déplacé vers le jugement — savoir quoi construire, comment structurer une application, et pourquoi une approche plutôt qu'une autre¹. L'enquête 2025 de Stack Overflow mesure le décalage : 84 % des développeurs utilisent ou prévoient d'utiliser des outils d'IA, mais 46 % se méfient de l'exactitude de leurs sorties, contre 33 % qui s'y fient⁵.

Les sections 1 à 5 suivent la présentation de Cedric Clyburn pour IBM Technology¹, que je complète par des chiffres sourcés et, à chaque étage, par ce que j'en ai vu en construisant Orthopy, un SaaS clinique aujourd'hui en bêta fermée. Viennent ensuite les questions à poser pour recruter un ingénieur IA, puis mon analyse de ce que ce découpage laisse de côté.

1. Un ingénieur IA n'est pas un chercheur en machine learning

Le métier est récent et se confond souvent avec celui de chercheur en ML. La distinction est pourtant nette¹ :

• Le chercheur en machine learning entraîne des modèles fondationnels depuis zéro, publie des papiers sur de nouvelles architectures et travaille avec des mathématiques profondes — un doctorat est souvent la porte d'entrée.
• L'ingénieur IA construit avec les modèles qui existent déjà, qu'ils soient frontières ou open source. Son travail consiste à les brancher sur des données, à leur donner accès à des outils et à de l'information externe, à ajouter mémoire, boucles de décision et garde-fous.

Si le chercheur construit le moteur, l'ingénieur IA construit la voiture. Et c'est la voiture qui manque aux organisations.

Autre conséquence : le diplôme en informatique n'est plus la seule porte d'entrée. Ce qui s'apprend mal en cours, c'est le jugement, et il s'acquiert en construisant ; des projets à montrer valent donc autant qu'un parcours classique¹.

2. Premier étage : les fondations

Ce premier étage n'a rien de spécifique à l'IA. L'ordre compte : ceux qui sautent directement aux agents passent ensuite leur temps à réapprendre les bases¹.

Sur le terrain. Ces bases ne sont pas décoratives quand des agents écrivent le code. Sur Orthopy, un type TypeScript écrit à la main annonçait un champ que l'API ne renvoyait pas : tout un assistant de l'application était inatteignable, alors que la suite de tests était entièrement verte. La leçon relève des fondations, pas de l'IA : générer les types du frontend depuis le schéma de l'API au lieu de les écrire à la main, c'est la première chose que je referais autrement. Côté Git, une étiquette de restauration est posée avant chaque tâche confiée à un agent, et chaque déploiement porte la sienne⁸.

3. Deuxième étage : les compétences IA appliquées

Embeddings et recherche vectorielle

Un modèle ne comprend pas vos documents tant qu'ils restent du texte. Les embeddings convertissent des contenus (PDF et autres formats) en vecteurs numériques, que l'on recherche par similarité : dans cet espace, « Kubernetes » se rapproche de « containers » et d'« orchestration »¹. Le système reconnaît alors le sens plutôt que de faire coïncider des mots-clés.

L'intérêt est concret : pouvoir injecter de l'information fiable dans la fenêtre de contexte d'un LLM pour obtenir des réponses exactes.

Le RAG, ou comment éviter les réponses inventées

Le RAG (retrieval augmented generation) sert à donner au modèle des résultats exacts sur une information précise — une politique d'entreprise, un document légal — au lieu de le laisser halluciner une réponse qu'il n'a jamais vue à l'entraînement¹. La méthode a un article fondateur : Lewis et al. (NeurIPS 2020) combinent la mémoire d'un modèle entraîné et un index vectoriel dense de Wikipédia interrogé par un récupérateur neuronal, et observent que ces modèles produisent un langage « plus spécifique, plus divers et plus factuel » qu'un modèle purement paramétrique⁴. Le pipeline tient en cinq étapes :

1. Les documents entrent dans le pipeline, découpés en morceaux de taille fixe adaptée à la base utilisée.
2. Chaque morceau est transformé en vecteur et stocké dans une base de recherche.
3. Une question arrive : on cherche dans la base les passages pertinents.
4. La question et les passages sont envoyés ensemble dans la fenêtre de contexte du LLM.
5. La réponse revient en langage naturel, ancrée dans les faits récupérés.

Selon Clyburn, presque toutes les entreprises qui expérimentent l'IA veulent une forme de RAG, même sans embeddings ni base vectorielle¹. Eurostat ne mesure pas le RAG en tant que tel, mais ses chiffres montrent où se concentre la demande : l'usage d'IA le plus répandu dans les entreprises de l'UE est l'analyse de langage écrit (11,8 % des entreprises en 2025), devant la génération d'images, de vidéos ou d'audio (9,5 %) et la génération de texte ou de parole (8,8 %)².

Sur le terrain. Savoir faire un RAG ne dispense pas de savoir quand ne pas en faire. Pour les règles de remboursement INAMI qu'applique Orthopy, j'ai écarté le RAG : un modèle n'offre aucune garantie déterministe sur un seuil de percentile, et une erreur signifie un dossier rejeté par la mutuelle. Les règles sont devenues des données versionnées, lues par du code testé : résultat 100 % déterministe, sans coût d'inférence, et mis à jour en quinze minutes quand l'INAMI a révisé ses listes⁸.

Les agents et l'usage d'outils

C'est le passage de « répondre à des questions » à « faire des choses » — selon Clyburn, la compétence IA appliquée la plus demandée du moment¹. La distinction centrale :

La vraie compétence n'est pas de monter une démo d'agent : c'est de construire ces boucles de façon fiable et à l'échelle¹. C'est là que se joue la différence entre un prototype et un système exploitable.

Sur le terrain. Une boucle d'agent peut dériver sans jamais planter. Sur la chaîne d'agents qui a produit Orthopy, chaque constat de revue devenait une nouvelle tâche de nettoyage : la part de ces cycles est passée de 12 % à 60 % en cinq semaines, et la file se nourrissait de ses propres constats. La correction n'a pas consisté à ajouter une règle, mais à changer celle qui produisait la dérive — et c'est une mesure de convergence, pas le nombre de tests verts, qui l'a révélée⁸.

Un mot de recul sur l'adoption réelle : les agents ne sont pas encore la norme chez les développeurs. 52 % ne les utilisent pas ou s'en tiennent à des outils d'IA plus simples, et 38 % n'ont pas l'intention d'en adopter⁵. Les prévisions des cabinets pointent pourtant vers un basculement : Gartner estime que d'ici 2028, la moitié des entreprises aura cessé de payer pour des copilotes assistatifs au profit de plateformes qui s'engagent sur des résultats de workflow, et décrit un rôle humain devenu « Agent Steward », qui supervise des résultats plutôt qu'il n'exécute les tâches⁶.

4. Troisième étage : la mise en production

Pour créer de la valeur, un système doit quitter l'ordinateur portable et atteindre de vrais utilisateurs. Trois briques en sont la condition¹ :

• La containerisation. Empaqueter l'agent — parfois le modèle lui-même — pour le déployer dans différents environnements. Docker, l'orchestration type Kubernetes et le cloud hybride sont les briques typiques.
• L'observabilité. Quand un agent interroge plusieurs bases, enchaîne les appels et tranche, il faut pouvoir répondre à une question simple : pourquoi cette décision finale ? Tracer chaque étape est ce qui rend l'IA explicable et digne de confiance.
• Le monitoring. Surveiller la facture de tokens, la sécurité et le reste des coûts d'exploitation, que le déploiement se fasse sur du matériel isolé ou dans un cloud hébergé.

Sur le terrain. Sur Orthopy, chaque appel au modèle de langage écrit une ligne dans un journal dédié : le verdict du contrôle de sortie et des compteurs, avec les identifiants remplacés par une empreinte, jamais une donnée patient. L'outil de suivi des erreurs masque les champs sensibles et abandonne l'événement si le masquage échoue. Côté coûts, le routage des modèles et un taux de réutilisation du cache supérieur à 90 % ramènent une tâche de la chaîne d'agents à 0,10–0,15 dollar⁸.

5. Les trois cas d'usage qui occupent le terrain

Pour démontrer ses compétences à un employeur, la présentation recommande trois projets, qui recoupent les trois cas d'usage les plus fréquents en production¹ :

1. Le RAG comme système de connaissance : services RH, hôpitaux, chatbots en ligne — permettre à des utilisateurs de poser des questions sur leur organisation et d'obtenir des réponses ancrées dans les documents réels.
2. Les agents et les outils : un agent qui interroge une base de données, visualise des résultats et fait ce qu'un expert métier faisait seul.
3. Les applications déployées : sortir un système du prototype pour le mettre entre les mains d'utilisateurs réels ; l'exemple donné est celui d'outils qui aident les ingénieurs à livrer leur code en heures plutôt qu'en semaines.

Le conseil pratique : construire dans ces trois zones, en les liant à ses intérêts propres. Un projet personnel qui résout un problème que vous connaissez vaut mieux qu'un tutoriel recopié.

La demande est au rendez-vous, au moins côté adoption : en 2025, 20,0 % des entreprises de l'UE (10 salariés ou plus) utilisaient au moins une technologie d'IA, contre 13,5 % en 2024². La Belgique affiche 34,5 % — derrière le Danemark (42,0 %), la Finlande (37,8 %) et la Suède (35,0 %) — avec 76,4 % des grandes entreprises belges²³. Parmi les développeurs qui utilisent déjà des agents au travail, 84 % s'en servent pour développer du logiciel ; tous répondants confondus, 52 % jugent que les outils ou agents d'IA ont eu un effet positif sur leur productivité⁵.

6. Recruter un ingénieur IA : les questions qui révèlent le jugement

Que ce soit pour embaucher ou pour choisir un prestataire, un constat s'impose : comme le code s'écrit de plus en plus vite, les connaissances techniques seules ne distinguent plus les profils. Ce qui fait la différence en entretien, c'est la qualité de l'explication et la calibration — savoir distinguer « je sais », « je suppose » et « je vais vérifier » — bien plus que la réponse finale. Voici les questions qui révèlent le jugement, dans deux contextes.

Entre spécialistes

Un filtre transversal : dans toutes les réponses, écouter s'il distingue « je sais », « je suppose », « je vais vérifier ». Celui qui affirme tout avec la même certitude livrera un système qu'il ne pourra pas défendre.

Du patron de PME au spécialiste

Le dirigeant ne peut pas vérifier la technique — il peut vérifier si l'échange le rend plus intelligent ou plus inquiet.

Critère transversal côté dirigeant : repartez-vous de l'échange plus intelligent ou plus inquiet ? Le spécialiste qui rend plus inquiet — sans décourager — protège ; celui qui rend euphorique vend.

7. Ce qui tient, et ce qui manque

Le déplacement vers le jugement tient. C'est aussi le constat central du retour d'expérience Orthopy : produire du code est devenu rapide, prouver qu'il est juste ne l'est pas⁸. Le même constat se lit dans le marché de l'emploi et dans la construction d'un SaaS réel. L'enquête Stack Overflow le confirme par un détail : ce sont les développeurs les plus expérimentés qui se méfient le plus des sorties d'IA, avec 20 % de méfiance forte⁵. Vérifier coûte du jugement, la ressource qui manque le plus.

L'ordre des étages tient aussi. Les paragraphes « Sur le terrain » ci-dessus racontent au fond la même chose : les problèmes sérieux relevaient des fondations (un type écrit à la main, des règles à sortir du modèle pour les mettre en données versionnées) et de la mesure (le ratio de nettoyage), rarement du choix du modèle.

Le manque : le cadre légal. Ce découpage des compétences, hérité d'un panorama anglo-saxon, ne dit rien du RGPD — ni du fait que ce que vous montrez à votre agent part chez le fournisseur du modèle. En Europe, le cadre existe et s'applique par paliers. Le règlement (UE) 2024/1689 (AI Act) classe les systèmes par niveau de risque, impose par exemple d'informer l'utilisateur d'un chatbot qu'il parle à une machine, et interdit plusieurs pratiques depuis février 2025. Ses règles pour les systèmes à haut risque s'appliqueront à partir du 2 décembre 2027 dans les domaines sensibles (biométrie, éducation, emploi…), et à partir du 2 août 2028 pour les systèmes intégrés à des produits⁷. S'y ajoute le RGPD dès qu'il y a des données personnelles : les conséquences concrètes sont détaillées dans l'article sur l'IA et les données patients. Un ingénieur IA formé uniquement sur la pile technique construira des systèmes qui fuient par le contrat, pas par le code.

En résumé

Le métier d'ingénieur IA ne demande pas un doctorat, mais un empilement de compétences dans l'ordre : les fondations (Python, Git, ligne de commande, APIs), puis les compétences IA appliquées (embeddings, RAG, agents et usage d'outils), puis la mise en production (containerisation, observabilité, monitoring). Le code ne fait plus la difficulté : le jugement, la fiabilité des boucles d'agent et la traçabilité la font. Côté recrutement, les questions de la section 6 valent plus qu'un CV : l'entretien révèle le jugement, et le code ne le cache plus. Et pour la partie que ce découpage n'aborde pas, le cadre européen, la question « où vont les données quand on interroge un modèle ? » reste la première à poser.

Concrètement, si vous démarrez : suivez l'ordre des trois étages, montez un projet RAG, puis un petit agent avec deux outils, puis déployez-les avec journaux et monitoring. Si votre organisation veut aller droit au cas d'usage sans repasser par la case formation, c'est précisément le genre de cadrage proposé en Conseil & Audit ; et pour une tâche concrète à automatiser, les Starters sont faits pour démarrer petit. Un premier échange se fait par la page de contact.

Sources

1. IBM Technology — « Essential Skills for Becoming an AI Engineer: RAG, AI Agents, & More », Cedric Clyburn (13 sept. 2026) : la présentation source des sections 1 à 5.
2. Eurostat — « 20 % of EU enterprises use AI technologies » (11 déc. 2025).
3. Eurostat — « The use of artificial intelligence (AI) technologies in the European Union », rapport KS-01-26-009 (2026).
4. Lewis et al. — « Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks », NeurIPS 2020.
5. Stack Overflow — Developer Survey 2025, section AI.
6. Gartner — « Most Enterprises to Abandon Assistive AI for Outcome-Focused Workflow by 2028 » (2 avr. 2026).
7. Commission européenne — AI Act, cadre réglementaire, règlement (UE) 2024/1689 (maj 3 août 2026).
8. Waelan — « Orthopy, du socle au déploiement : retour d'expérience » (13 sept. 2026).