Applied AI Engineer (agents IA de programmation)

L’ingénieur agents IA de programmation, ou Applied AI Engineer spécialisé dans les agents de programmation, conçoit et améliore des systèmes capables d’accomplir des tâches sur un dépôt logiciel. Un tel agent reçoit une tâche, utilise des outils dans un environnement d’exécution, agit en plusieurs étapes et peut modifier du code. Le résultat se contrôle notamment par des tests. Le poste porte sur le fonctionnement et la qualité de cet agent, au-delà de l’usage quotidien d’un assistant de code.

Selon l’organisation, l’ingénieur travaille sur la boucle qui organise les actions de l’agent, sur les outils auxquels celui-ci accède, sur ses instructions et ses garde-fous, ou sur l’évaluation des résultats. Ces responsabilités peuvent appartenir à des équipes distinctes. Chez Cursor, par exemple, des offres séparent la conception du système agent de l’évaluation et de la qualité. Il faut donc décrire le périmètre attendu avant de chercher un candidat.

Le système traite des tâches de programmation telles que l’écriture de tests, la correction de bugs ou l’ajout de fonctionnalités. L’ingénieur du poste ne réalise pas nécessairement lui-même chaque modification de code demandée aux agents. Il construit les conditions dans lesquelles ces modifications peuvent être exécutées, examinées et améliorées.

Ingénieur agents IA, ingénieur logiciel et spécialiste des évaluations : qui fait quoi ?

• Ingénieur agents IA de programmation : travaille sur la boucle d’exécution, les outils et la mesure de qualité de l’agent, selon le mandat défini.
• Ingénieur logiciel : peut intégrer ou utiliser un agent dans un produit sans avoir la responsabilité durable de son comportement.
• Spécialiste des évaluations : se concentre sur les tâches de test, les critères, les régressions et l’analyse des échecs. Cette responsabilité peut former une équipe distincte.

Cette distinction sert à cadrer le recrutement. Elle ne fige ni les intitulés de poste ni la répartition des responsabilités entre entreprises.

Un agent de programmation peut agir sur un dépôt et modifier son environnement de travail. La fiabilité de l’agent dépend donc autant de sa manière d’agir que du résultat visible. Un comportement convaincant sur une démonstration ne suffit pas à établir sa fiabilité sur d’autres tâches. Les tests, les traces d’exécution et l’analyse des échecs aident à distinguer une amélioration réelle d’un effet limité à quelques cas.

Le premier arbitrage porte sur le périmètre. Si les difficultés concernent l’enchaînement des actions, les outils ou l’environnement d’exécution, le travail ressemble à la conception du système agent. Si elles concernent les résultats difficiles à mesurer ou les régressions, il faut renforcer l’évaluation. Les offres de Cursor montrent ces deux spécialisations, sans imposer cette division à toutes les entreprises. Une fiche de poste qui additionne toutes ces missions sans ordre de priorité rend l’autonomie attendue difficile à juger.

Le second arbitrage porte sur ce que mesure une évaluation. Les tâches choisies, la configuration de l’agent et les critères employés influencent le résultat. Microsoft précise, pour sa plateforme Scope, qu’un score ne constitue pas un classement universel et qu’un jugement automatique peut demander une revue humaine. Le recrutement doit donc privilégier une personne capable d’expliquer ce que ses tests démontrent et ce qu’ils laissent ouvert.

Exemple fictif : un agent réussit une série de corrections courtes, mais échoue lorsque la tâche exige de lire plusieurs fichiers et de lancer des tests. Avant d’ajuster le modèle, l’ingénieur examine les outils disponibles, les étapes suivies et les traces de l’échec. Il modifie ensuite un élément du système et rejoue les tâches pour voir si le changement tient.

Enfin, la qualité perçue, la fiabilité et le coût peuvent entrer en tension. Les choix de modèle, d’outils et de comportement dépendent du produit et des contraintes de ses utilisateurs. Le candidat doit pouvoir justifier ces choix avec les données disponibles, sans présenter une préférence technique comme une vérité générale.

• Concevoir la boucle d’exécution qui organise les étapes et les appels d’outils de l’agent.
• Choisir les outils accessibles à l’agent et préciser leurs fonctions et leurs limites.
• Adapter les instructions et l’environnement d’exécution aux tâches de programmation visées.
• Définir des tâches représentatives et des critères pour évaluer les changements de comportement.
• Lancer des tests et des évaluations pour repérer les régressions après une modification.
• Analyser les traces et les échecs afin de distinguer un défaut d’outil, de contexte ou de comportement.
• Interpréter les signaux d’usage pour prioriser les améliorations pertinentes au produit.
• Expliquer les compromis entre qualité des résultats, expérience utilisateur et coût selon le contexte.

Aucun diplôme unique ne définit cette spécialisation. Un parcours en développement logiciel peut apporter la maîtrise du code, des tests et des environnements d’exécution. Une expérience en conception d’outils peut préparer à définir les fonctions accessibles à l’agent et le contexte qu’ils lui renvoient. L’ingénierie des évaluations développe la capacité à construire des tâches représentatives, à interpréter les traces et à repérer les régressions. Ces acquis peuvent se combiner de différentes façons ; aucune formation ni durée d’expérience unique n’est imposée pour ce poste. Des réalisations en code, tests ou outils peuvent montrer une progression vers cette spécialisation, même si le poste précédent portait un autre nom. Le périmètre de chaque réalisation compte : contribution à un outil, construction d’un dispositif d’évaluation ou responsabilité sur le comportement de l’agent ne demandent pas le même degré d’autonomie. Cette distinction aide à définir le niveau visé sans exiger un parcours uniforme.

Le niveau attendu dépend du mandat. Améliorer un composant précis demande moins d’autonomie que définir le programme d’évaluation d’un produit. Une expérience de développement peut être pertinente si elle s’accompagne d’un travail sur le fonctionnement ou la qualité de l’agent, au-delà de son utilisation. L’intitulé antérieur du poste renseigne moins que les responsabilités effectivement exercées.

Pour évaluer ce profil, suivez ces étapes et reliez les compétences du poste à des éléments observables.

1. Fixer les critères avant les entretiens

Précisez si le poste porte d’abord sur la boucle d’exécution, les outils ou la qualité de l’agent. Choisissez quelques critères liés à ce mandat : solidité du code, choix des outils, conception de tests, lecture des traces et jugement sur les résultats. Indiquez le degré d’autonomie attendu pour chaque décision. Un signal favorable est la capacité à relier chaque critère à une tâche réelle du produit. Restez vigilant si le profil recherché additionne des responsabilités sans priorité ni interlocuteur chargé de valider les résultats.

2. Examiner une réalisation passée

Demandez au candidat de raconter une modification apportée à un agent ou à son dispositif d’évaluation. Faites préciser la tâche, les outils disponibles, les tests et les échecs rencontrés. Cherchez ce qu’il a décidé lui-même et ce qui relevait de son équipe. Un bon récit explique aussi une limite : par exemple, pourquoi un résultat sur certaines tâches ne prédit pas toutes les autres. Si la personne attribue une amélioration à un seul changement sans avoir examiné les autres paramètres, approfondissez sa démarche.

3. Proposer un cas proche du poste

Utilisez un petit dépôt fictif ou un dossier d’évaluation fabriqué pour l’exercice. Vous pouvez demander au candidat de choisir les outils qu’un agent devrait recevoir, de définir un test de réussite ou d’analyser une trace d’échec. Fixez un temps raisonnable et donnez les mêmes éléments à tous les candidats. Exemple fictif : un agent modifie le bon fichier, mais omet un test qui révèle une régression. Demandez quelle information manque, quel changement essayer et comment vérifier son effet. Évaluez la démarche et les limites reconnues, sans faire du nombre de lignes produites le seul critère.

4. Observer la communication et les arbitrages

Invitez le candidat à expliquer ses choix à une personne chargée du produit et à une personne chargée de l’ingénierie. Faites-lui distinguer qualité mesurée, expérience utilisateur et coût lorsque ces sujets se présentent dans votre contexte. Un signal favorable est une décision motivée par les tâches observées et les contraintes explicites. Soyez attentif à une conclusion générale tirée d’un seul score. Les résultats d’évaluation dépendent des tâches et des configurations testées ; un jugement automatique peut demander une revue humaine.

5. Recouper les éléments

Avec l’accord du candidat, demandez à une référence professionnelle quel périmètre il a effectivement tenu : conception, tests, diagnostic ou coordination. Cherchez des exemples de décisions et de collaboration plutôt qu’une appréciation vague. Si votre entreprise n’a pas l’expertise nécessaire pour juger le cas technique, associez un ingénieur expérimenté en logiciels ou en évaluations d’agents. Communiquez-lui la grille de critères et demandez une justification écrite des observations. Comparez ensuite les éléments recueillis avec le mandat initial, sans transformer un exercice limité en jugement universel.