Des démos à essayer, sans connexion

Études de cas

• ESN spécialisée en qualité logicielle, lancement d’une plateforme RAG souveraine interne : aucune stratégie d’évaluation établie au démarrage.

  Mesurer la fiabilité d’un RAG souverain, pas seulement le construire

  Problème

  Un système RAG qui répond de façon plausible ne veut pas dire qu’il répond juste. En testant le connecteur vers Jira, le chatbot renvoyait des réponses crédibles alors que la connexion échouait silencieusement — aucune erreur levée, les tests d’intégration passaient malgré tout.

  Démarche

  Jeu de questions de référence par profil métier (golden dataset), juge automatique (LLM-as-judge) instrumenté via Langfuse, seuils de qualité ancrés en gouvernance (fidélité ≥ 0,80) et rendus réellement bloquants en CI — une protection de branche empêche la fusion si le score chute. Chaque amélioration traitée comme une expérience : hypothèse, mesure avant/après, décision.

  • 0,54 → 0,63fidélité des réponses, après correction d’un banc de mesure flatteur puis reranking
  • 44 % → 0 %taux d’erreur sous charge à 25 utilisateurs simultanés
  • 0,84 → 0,27un indicateur de rappel démasqué comme artefact de mesure, corrigé avant qu’il ne devienne un problème client

  La rigueur doit porter sur l’instrument de mesure lui-même, pas seulement sur le système qu’il évalue — un score qui semble bon peut être un banc de test qui ment.

• Deuxième cas d’usage bâti sur le même socle RAG souverain que le précédent : un automate de publication éditoriale, pour prouver que l’architecture se réutilise au-delà d’un seul produit.

  Un automate IA qui tient en production, pas une démo qui tourne une fois

  Problème

  Un automate sans supervision ne prévient jamais qu’il a raté un créneau — les premières publications planifiées ont été perdues en silence, une fois sur une panne Docker, une fois sur un rechargement de modèle trop lent.

  Démarche

  Développement piloté par les tests de bout en bout (ingestion, agent de rédaction, publication, planification), garde-fou qualité avant toute action réseau (modération + juge automatique + anti-répétition), puis durcissement ciblé sur chaque panne réellement rencontrée : marge de rattrapage sur les créneaux manqués, préchauffage du modèle au démarrage, surveillance active du service d’inférence.

  • 9 joursde zéro à un automate publiant réellement, sans intervention (7 lots, 3 versions, 28 PR)
  • ~17 min → ~81 stemps de première publication après un démarrage à froid, une fois le préchauffage en place
  • 173 testsverts (unitaires, intégration, contrat) avant chaque mise en production

  Un socle bien conçu se réutilise : le même cœur RAG sert un chat documentaire et un automate de publication, deux métiers différents, sans être reconstruit.

• Institut de recherche en santé publique (anonymisé), sur la thématique du retour à l’emploi après un cancer — démonstration d’un assistant documentaire souverain auprès de chercheurs et d’un médecin du travail.

  Une démo qui fait pivoter le produit, pas qui confirme un cahier des charges

  Problème

  Le besoin exprimé au départ — informer le patient sur ses droits — était déjà couvert par un outil existant. La démo l’a révélé en direct : ce n’était pas le vrai besoin.

  Démarche

  Démo structurée en deux volets (parcours déterministe + chat RAG sourcé, données silotées par région) pour donner aux participants prise sur le système plutôt qu’un discours sur le système. Débrief formalisé en décisions tracées et arbitrages restant à trancher, pas en compte-rendu d’impressions.

  • 1 pivotcible produit déplacée d’un outil d’information patient vers un outil d’aide à la décision pour les professionnels
  • 5 décisions actéesdont le périmètre exact des données partageables (résultats anonymisés uniquement, jamais de donnée brute)
  • 3 pistes de financementchiffrées et priorisées dans la foulée de la démo (30 k€ à 300 k€)

  Une bonne démo ne sert pas à valider un cahier des charges écrit à l’avance — elle sert à mettre le vrai besoin en évidence, y compris quand il contredit la demande initiale.

• Écosystème de ~22 microservices en production (portail Solsticial), conduit en trio développeur humain + agents IA, CI/CD auto-hébergée.

  Retrouver la cause d’un bug intermittent avec des preuves, pas des suppositions

  Problème

  Une boucle de reconnexion intermittente touchait les utilisateurs en production depuis plus de dix jours. Plusieurs pistes d’investigation avaient déjà été écartées une à une, par la preuve et non par supposition — sans trouver la cause.

  Démarche

  Activation ciblée de journaux détaillés sur le service concerné, lecture des journaux réels au moment exact d’une reproduction en direct plutôt qu’une nouvelle hypothèse de plus. La trace a isolé un appel précis partant sans authentification, remonté jusqu’à la ligne de code en cause.

  • < 1 jourentre l’obtention des vrais journaux d’incident et le correctif corrigé, testé et déployé
  • 0 régressionsur les 488 tests de la suite existante après le correctif
  • 1 panne récurrente résoluesur l’infrastructure CI (tous les deux jours), par une parade pérenne plutôt qu’un nettoyage manuel répété

  Sur un système distribué, la preuve vient des journaux réels au moment exact de l’incident — jamais de la seule lecture du code, aussi minutieuse soit-elle.