Depuis deux ans, j’ai collaboré avec des experts en ingénierie — ingénieurs de processus, ingénieurs en fiabilité, analystes cybersécurité — pour concevoir des outils alimentés par des modèles linguistiques à grande échelle (LLM). Ces professionnels passent leur journée à analyser des logs, des spécifications, des schémas et des rapports, en effectuant des tâches comme le dépannage, l’analyse des modes de défaillance, la planification de tests ou les vérifications de conformité. L’objectif est séduisant : grâce à leur connaissance pré-entraînée, les LLM pourraient raisonner comme des experts, accélérant les tâches répétitives et répétitives, libérant ainsi les experts pour des décisions de haut niveau. En pratique, cependant, le chemin est semé d’embûches. « Ajouter simplement une boîte de chat » ne suffit pas à créer un outil utile. Un large écart subsiste entre un démonstrateur impressionnant et un système que les ingénieurs utilisent réellement. Ces leçons, issues de projets concrets, s’organisent en trois phases : avant, pendant et après le développement. Avant de commencer : le fondement du succès. La leçon 1 insiste sur le fait que tous les problèmes ne sont pas adaptés aux LLM. Avant d’adopter une solution basée sur l’IA générative, il faut se demander si un moteur de règles, un modèle classique d’apprentissage automatique ou une approche analytique ne suffirait pas. Les LLM brillent lorsqu’il s’agit d’interpréter, synthétiser ou générer du langage à partir de documents hétérogènes (ex. : trier 50 rapports d’incident). Mais ils sont coûteux, lents, et peu déterministes. Si le besoin est de résultats numériques précis, reproductibles, il vaut mieux rester sur des modèles classiques. De même, si l’humain n’est pas en boucle de validation, le risque d’erreurs graves est élevé. La leçon 2 insiste sur le positionnement du outil : il doit être un amplificateur, non un remplaçant. En disant clairement que l’objectif est d’aider, non de remplacer, on gagne la confiance des experts. Cela change la dynamique : une erreur du LLM devient une suggestion à affiner, pas un échec systémique. La leçon 3 insiste sur la co-conception : il faut impliquer les experts dès le début pour définir ce que « mieux » signifie. En observant leur workflow, en notant leurs points de douleur, on peut définir des métriques concrètes (temps de triage gagné, faux positifs réduits, étapes manuelles supprimées). Cela crée un cadre de benchmark clair et renforce la confiance. Pendant le projet : l’ingénierie du système. La leçon 4 prévient contre l’autopilote : un outil qui agit seul est peu fiable. Mieux vaut un co-pilote : le LLM propose des regroupements d’alertes, des hypothèses, des étapes, mais l’ingénieur valide, ajuste, approuve. Cela donne le sentiment de contrôle, essentiel à l’adoption. La leçon 5 conseille de ne pas se précipiter sur un framework (LangGraph, AutoGen, etc.). Pour le prototype, un simple appel à l’API OpenAI ou Google GenAI suffit. L’objectif est de valider rapidement si le LLM apporte de la valeur, pas de choisir l’outil le plus « moderne ». On peut structurer le pipeline avec des conditions, des boucles, des appels de fonctions — sans framework. La leçon 6 recommande de privilégier les workflows déterministes aux agents agiles. Dans l’ingénierie, les processus sont souvent bien définis. Plutôt que de laisser l’IA « redécouvrir » un workflow, il vaut mieux le coder explicitement, en intégrant le savoir-faire du domaine. Cela réduit le bruit, améliore la fiabilité et la transparence. La leçon 7 insiste sur la structuration : les LLM fonctionnent mieux avec des entrées et sorties structurées. Convertir des rapports en JSON, extraire les causes suspectées, les symptômes, les horaires, permet au LLM de raisonner plus précisément, de citer ses sources, et d’être plus facilement vérifiable. Cela s’applique aussi au RAG : récupérer des données structurées est plus précis que des documents bruts. La leçon 8 rappelle de ne pas oublier l’IA analytique. Les modèles classiques (clustering, détection d’anomalies, prévision) sont fiables, rapides, et échappent aux hallucinations. Une approche hybride — analytique pour le traitement de données, LLM pour l’explication et les recommandations — est souvent optimale. Après le développement : l’adoption. La leçon 9 insiste sur l’intégration dans l’environnement de travail réel. Un outil en dehors des outils existants (log viewer, système de ticket) sera ignoré. L’idéal : intégrer des boutons « résumer », « suggérer des étapes » directement dans l’interface qu’utilisent les ingénieurs. Le contexte (incident, fenêtre temporelle) doit être transmis automatiquement. La leçon 10 insiste sur l’évaluation continue. Le système doit montrer son raisonnement : quels documents a-t-il consultés ? Quels pas a-t-il faits ? Quel niveau de confiance a-t-il attribué ? L’explication doit être claire, citée, structurée. Enfin, des sessions d’évaluation avec des experts sur des cas réels permettent de recueillir des retours concrets, de mesurer l’impact, et d’itérer. En résumé, ces leçons tournent autour de trois piliers : respecter l’expertise métier, concevoir un système fiable et contrôlable, et considérer le déploiement comme le début, non la fin. Les LLM ne sont qu’un outil parmi d’autres — leur force réside dans l’ingénierie de l’ensemble, pas dans la technologie seule.