Le rôle de l’ingénieur en intelligence artificielle évolue rapidement, mais il reste profondément ancré dans les fondamentaux du génie logiciel. Contrairement à ce que suggèrent parfois les discours médiatiques, l’ingénierie en IA n’est pas tant une discipline radicalement nouvelle qu’une couche de complexité ajoutée au développement logiciel traditionnel. Dans la plupart des entreprises, on ne construit pas de modèles depuis zéro. L’essentiel du travail consiste à intégrer des modèles pré-entraînés — via des APIs, des pipelines RAG, l’appel d’outils — tout en assurant la robustesse, la scalabilité et la maintenance du système, comme dans toute application logicielle. Cette évolution se structure autour de trois couches clés : le développement d’applications, le développement de modèles, et l’infrastructure. La plupart des équipes commencent par la couche supérieure : concevoir une application fonctionnelle à l’aide de modèles disponibles. C’est ce que l’on appelle, selon O’Reilly, « du génie logiciel avec des modèles d’IA intégrés dans la pile ». L’IA n’a pas remplacé le logiciel ; elle l’a enrichi. Un pilier central de ce nouveau paradigme est l’évaluation (evals). En logiciel classique, les tests permettent de détecter les régressions avant qu’elles ne deviennent critiques. En IA, chaque modification — une reformulation de prompt, un changement dans un pipeline RAG, une mise à jour de modèle — peut améliorer les performances dans un domaine tout en détériorant celles dans un autre. Les évaluations sont donc les gardiens de la fiabilité, permettant de progresser vite sans briser l’application. Cependant, évaluer l’IA est bien plus complexe qu’évaluer un programme déterministe. Les modèles sont intelligents, mais leurs sorties sont souvent floues, ouvertes à l’interprétation, et parfois difficiles à juger objectivement. Il n’y a pas toujours une réponse unique correcte. De plus, les modèles sont souvent des « boîtes noires » : leur architecture, leurs données d’entraînement ou leurs processus sont inaccessibles, ce qui limite la capacité à évaluer leurs limites. Pour faire face à ces défis, on distingue deux types d’évaluations : quantitatives et qualitatives. Les évaluations quantitatives, comme la vérification de la correction d’un calcul ou du bon fonctionnement d’une fonction, peuvent être automatisées. Les évaluations qualitatives, quant à elles, portent sur des jugements subjectifs : la clarté d’un message, la pertinence d’un résumé, la tonalité d’un chatbot. Elles nécessitent des critères bien définis — par exemple, une échelle de 1 à 5 pour la « pertinence » ou la « courtoisie » — et peuvent être confiées à un modèle « juge ». L’idée d’« évaluation pilotée » (eval-driven development), inspirée du test-driven development, est particulièrement puissante. Elle consiste à définir les critères de succès avant même de coder. Cela garantit que l’IA apporte une valeur réelle, mesurable, et alignée sur les besoins métiers. Il faut aller au-delà de la simple correction : il faut évaluer la faisabilité (temps d’exécution, consommation mémoire), la cohérence locale (respect du contexte fourni) et globale (vérification contre des sources externes), ainsi que la sécurité (protection des données, résistance aux attaques par prompt). Enfin, les évaluations automatisées, notamment via des modèles juges, permettent d’implémenter des pipelines d’évaluation continues, intégrés aux processus CI/CD. Cela permet de détecter rapidement les dérives ou les régressions, même dans des systèmes probabilistes. En résumé, l’ingénierie en IA n’est pas une rupture, mais une évolution. Elle exige des ingénieurs capables de jongler entre logiciel, IA, intuition produit et empathie utilisateur. Les évaluations robustes sont désormais la pierre angulaire de la qualité logicielle dans un monde où les systèmes ne sont plus déterministes, mais probabilistes. C’est là que réside le vrai défi : maintenir la confiance, l’efficacité et la valeur — sans sacrifier la vitesse.