Contexte technique
Je décrirais le rôle d’un AI Engineer de manière très terre-à-terre : je ne « fais pas d’IA », je construis un système qui ne s’effondre pas après le premier utilisateur réel. Il s’agit généralement d’automatisation IA autour des LLM : RAG, agents, appels d’outils, validations, réessais, traçage et de vrais critères de qualité.
En bref, mon travail commence là où s’arrête la belle démo. On peut presque toujours monter un prototype rapidement. Mais le faire évoluer jusqu’à ce qu’il ne gaspille pas de tokens, ne mente pas une fois sur deux et ne casse pas le processus métier, c’est là qu’est la véritable ingénierie.
Je me heurte constamment à trois blocs. Premièrement : comprendre les limites du modèle, ce qu’il sait vraiment faire et où il commence à inventer. Deuxièmement : concevoir un pipeline où chaque étape a des conditions de sortie, des vérifications de format, des fallbacks et un coût d’erreur clair. Troisièmement : mettre en place des évaluations pour ne pas croire l’agent sur parole.
Curieusement, ce sont souvent les évaluations qu’on néglige, et c’est une erreur. Je ne me contente pas de regarder « mieux ou moins bien », mais des jeux de référence, des jeux de régression, des tranches d’échec, des comparaisons par paires, une revue humaine et les signaux en ligne de la production. Si le système effectue de la classification, de l’extraction ou de la récupération, alors on passe aux métriques de précision, rappel, F1, intervalles de confiance et tests A/B. Sans cela, toute discussion sur la qualité n’est que conjecture.
Une autre partie sous-estimée du travail, que j’observe tant dans mes projets que dans ceux des clients, est l’ingénierie du contexte. Comment découper la mémoire, quoi mettre en cache, où placer un préfixe stable, comment versionner les prompts, quand effectuer un appel d’outil et quand une logique métier stricte est préférable. C’est à ce moment que l’intégration IA commence à générer des revenus ou se transforme en un jouet coûteux.
Impact sur les affaires et l’automatisation
Pour les entreprises, la conclusion est simple : les gagnants ne sont pas ceux qui ajoutent un chatbot en premier, mais ceux qui savent mesurer les résultats. Sans évaluations ni traçage, impossible de savoir si le système aide ou fait juste du bruit.
Le deuxième point concerne l’architecture des coûts. Un pipeline bien conçu apporte souvent plus d’effet qu’un changement de modèle : le cache, le traitement par lots, le routage économique, les validations avant un appel coûteux et des fallbacks appropriés réduisent les coûts davantage qu’une énième version « intelligente ».
Les équipes perdantes sont celles qui considèrent l’AI Engineer comme la personne « pour tous les cas magiques ». Ce rôle est depuis longtemps une question de conception système et de discipline en production. Chez Nahornyi AI Lab, nous analysons précisément ces goulets d’étranglement avec nos clients : où un agent est nécessaire, où RAG suffit, et où il vaut mieux ne pas implémenter d’IA du tout pour éviter une complexité inutile.
Si vous avez déjà un prototype dont la qualité fluctue, qui dévore le budget ou qui s’emmêle dans les étapes, examinons ensemble votre flux. Chez Nahornyi AI Lab, je trouve généralement rapidement où un développement ciblé de solution IA est nécessaire et où il suffit de restructurer soigneusement l’automatisation IA sans bruit ni surcoût.