Le 15 mai 2025 s’est tenue l’édition 2025 du Cloud Toulouse. À cette occasion, l’équipe Ippon Toulouse a eu le plaisir d’assister à plusieurs conférences. Cet article, rédigé par nos collaborateurs, a pour objectif de vous partager un aperçu de certaines interventions qui ont particulièrement retenu notre attention.

Article co-écrit par Hanae RHAYOUR, Justin AUBIN, Dimitri Jean CLAIN, Nicolas HURTEVENT et Tanoh N’GOYET.

Sommaire

• Détective de la prod : Résoudre l'enquête avant le crash
• Bienvenue à la Green Software Foundation
• Comment créer son jeu de rôle en Agentic AI & MCP
• Protéger les données à l'ère de l'IA
• La santé a-t-elle peur du cloud ?

Détective de la prod : Résoudre l'enquête avant le crash

Hanae RHAYOUR
Conférence présentée par Sebastien FERRER, OVH Cloud.

Lors de cette conférence, Sébastien FERRER nous a déroulé une logique (généralisable) pour gérer des incidents multi-projets, sans nécessairement les connaître ou les maîtriser. Cette logique passe par de bonnes pratiques lors de la phase de build, puis par un certain nombre de méthodes de debug.

De manière générale, les incidents sont détectés via des alertes issues du monitoring, du code ou des logs. Un suivi quotidien est assuré grâce à des dashboards de contrôle et des indicateurs clés comme le TTA (Time to Acknowledge) et le TRS (Time to Restore Service) pour mesurer la réactivité et la résolution.

Méthodes d’investigation 

Plusieurs méthodes permettent de résoudre les problèmes rapidement et précisément :

• History based method : s’appuyer sur l'historique de problèmes similaires pour gagner du temps. 
• Bottom-up : le matériel → couche réseau → code . Creuser étape par étape, bien que cette méthode peut être longue et chronophage. 
• Five why’s : méthode qui paraît simple mais puissante et qui consiste à se poser 5 fois la question “pourquoi” et ainsi remonter à la cause racine. 
• RCA : root cause analysis. Se concentrer sur l’identification du problème réel plutôt que sur ses symptômes.

Bonne pratiques pour les logs

Il est important d’assurer une bonne qualité des logs pour assurer une résolutions efficace des incidents : 

• Apporter des informations essentielles et claires tout en limitant le bruit généré par des logs inutiles.
• Avoir une structure de logs identifiable : info, warning, error. Sans oublier d’ajouter des identifiants pertinents. Exemples : id utilisateur, IPs, code d’état … 
• Une bonne organisation des logs, qui facilite les requêtes. 
• Ajouter des règles d’alerte et le niveau de criticité. 
• Utiliser l’error wrapping pour apporter du contexte aux erreurs.
• Utiliser un Linter pour garantir la qualité des logs.

Conclusion

Réussir à éviter un crash et résoudre efficacement les incidents, passe par une méthode d’investigation rigoureuse et une bonne gestion des logs et du monitoring. Une telle approche permet d’identifier efficacement et rapidement la cause du problème et de le résoudre dans les meilleurs délais.

Bienvenue à la Green Software Foundation

Justin AUBIN
Conférence présentée par Julien LANDURÉ, fondateur et CTO de TechTown.

TL;DR

• La Green Software Foundation (GSF), fondée sous l'égide de la Linux Foundation, œuvre pour rendre le développement logiciel plus durable.
• Elle propose des outils et des formations pour mesurer, comprendre et réduire les émissions de carbone des logiciels.
• La fondation encourage une approche communautaire et pédagogique.
• Parmi ses projets phares : la spécification Software Carbon Intensity (SCI), le Maturity Matrix et l'Impact Framework.

Lors de sa conférence à Cloud Toulouse, Julien LANDURÉ nous a présenté la Green Software Foundation (GSF), une initiative open source placée sous l’égide de la Linux Foundation. Cette fondation s’est donnée pour mission de proposer un écosystème (formation, normes, outils, spécifications, etc) afin de réduire l’impact environnemental associé à la production et à l'utilisation de nos outils informatiques.

L’approche de la GSF s’articule autour de trois grands piliers :

• Energy Efficiency : utiliser le moins d’énergie possible (ex: écrire du code optimisé)
• Hardware Efficiency : mieux utiliser les ressources matérielles (ex: éviter le surdimensionnement des serveurs)
• Carbon Awareness : prendre en compte l’intensité carbone selon le moment et l’endroit d’exécution (ex: exécuter un job quand l’électricité est décarbonée).

Parmi les initiatives/outils de la GSF, on trouve :

• Software Carbon Intensity (SCI) Specification, une spécification pour calculer l'intensité carbone des logiciels.
• Impact Framework, qui permet d'observer et d'évaluer l'impact environnemental des infrastructures.
• Maturity Matrix : une matrice d’évaluation pour aider les entreprises à progresser dans leur maturité “green”.
• Awesome Green Software : une liste collaborative de ressources, outils et bonnes pratiques.

La GSF ne se limite pas à la technique : elle joue un rôle pédagogique essentiel dans un contexte où le GreenOps (la démarche écologique appliquée aux opérations IT) reste encore peu connu et peu appliqué. Elle propose :

• Une courbe de progression claire, illustrée par un schéma en trois étapes : comprendre, étudier pour réduire, passer à l’action.
• Des contenus de formation accessibles, dont le cours en ligne gratuit Green Software for Practitioners (LFC131).
• Des événements communautaires (meetups, hackathons, live sessions) pour faire émerger une culture du numérique responsable, fédérer les acteurs et partager les retours d'expérience.

L’objectif est aussi de faire évoluer les pratiques du secteur : comprendre que la sobriété numérique ne se limite pas à compenser les émissions (net-zero), mais qu’elle passe d'abord par la réduction directe des émissions évitables.

Pour les devs curieux ou motivés par le numérique responsable, c’est un excellent point de départ pour s’informer et passer à l’action.

Comment créer son jeu de rôle en Agentic AI & MCP

Dimitri Jean CLAIN
Conférence présentée par Tiffany SOUTERRE et Arnaud JEAN.

Lors d'une récente conférence dédiée à l'intelligence artificielle, une démonstration captivante a mis en lumière la puissance des agents IA dans un contexte ludique : la gestion de parties de jeux de rôle. En s'appuyant exclusivement sur les services AWS, cette présentation a illustré comment l'IA peut assister les maîtres de jeu (MJ) dans la création, la gestion et l'orchestration de leurs campagnes.

Qu'est-ce qu'un agent IA ?

Un agent IA est une entité autonome capable d'interagir avec des bases de données, des API et divers services pour accomplir des tâches spécifiques. Dans le cadre de cette démonstration, plusieurs agents spécialisés ont été déployés :

• Le Constructeur d'histoire génère des scénarios narratifs cohérents.
• Le Vérificateur de règles se base sur un RAG pour s'assurer du respect des règles du jeu.
• Le Gestionnaire de personnages : supervise les fiches et l'évolution des personnages et les stocke via une base de données.
• L'Orchestrateur coordonne l'ensemble des agents pour une expérience fluide.

Les services AWS au cœur de l'expérience

La démonstration s'est appuyée sur plusieurs services AWS pour mettre en œuvre ces agents :

• Amazon Bedrock : plateforme qui permet de créer, personnaliser et déployer des applications d'IA générative en utilisant des modèles de fondation de divers fournisseurs.
• Guardrails pour Amazon Bedrock : fonctionnalité qui permet de définir des règles pour contrôler les entrées et sorties des modèles d'IA, assurant ainsi des réponses appropriées et sécurisées.
• Action Groups (tools) : permettent de définir des actions spécifiques que les agents peuvent effectuer, telles que la création ou la gestion de personnages.

En plus des services AWS natifs, deux briques techniques ont été utilisées pour faciliter l’orchestration et l’interopérabilité entre les agents :

• Model Context Protocol (MCP) : un protocole open-source de standardisation qui définit comment un agent (client) interagit avec des outils (serveur). MCP permet notamment de rendre l’architecture plus modulaire en séparant la logique métier du traitement IA. Chaque agent devient ainsi un « client » capable d’appeler différents outils, quel que soit leur langage ou leur environnement d’exécution. Github - Open Source MCP
• Agent Squad : un cadre de développement (framework) proposé par AWS Labs pour gérer des systèmes multi-agents. Il permet de faire collaborer plusieurs agents spécialisés autour d’un objectif commun (comme une session de jeu de rôle). Chaque agent peut être configuré avec son propre contexte, ses règles, et son mode de dialogue, facilitant une coordination riche et flexible.

Conclusion

Cette démonstration illustre le potentiel des agents IA dans des applications concrètes et ludiques. En combinant les services AWS, il est possible de créer des assistants intelligents capables de gérer des tâches complexes, offrant ainsi aux maîtres de jeu un outil puissant pour enrichir leurs parties. Au-delà du jeu, cette approche ouvre des perspectives intéressantes pour d'autres domaines nécessitant une coordination intelligente entre différents agents IA.

Protéger les données à l'ère de l'IA

Nicolas HURTEVENT
Conférence présentée par Carmen PICIORUS du groupe La Poste.

Dans une quickie de 15 minutes, Carmen PICIORUS du groupe La Poste nous a partagé ses expériences et les défis rencontrés avec l'utilisation des RAGs (Retrieval-Augmented Generation) pour leur chatbot interne, ainsi que les risques de fuite de données et les moyens de les éviter.

TL;DR

• Ne donnez pas d'informations confidentielles à vos chatbots !
• Cependant, comme on ne contrôle pas tout, certains utilisateurs risquent de le faire. Il est essentiel de s’en prémunir avec les outils appropriés.
• Presidio : pour anonymiser ou pseudonymiser les données.
• LLM Guard : pour éviter les injections de prompt, détecter le langage offensif ou les biais de formulation.

Aujourd'hui, 77% des entreprises bloquent l'utilisation de l'IA, qui reste à ce jour une boîte noire hors de nôtre contrôle. Les régulations sur l’IA commencent à arriver et il en existe déjà, comme l'IA Act, mais elles concernent principalement l'entraînement des modèles. Or, dans la majorité des cas, on ne ré-entraîne pas un RAG. Dans tous les cas, le RAG se base sur un modèle existant, on ne peut donc pas dire qu'on contrôle l'IA, car nous n'avons pas eu la main sur l'entraînement du modèle.

Cas Pratique

Une anecdote saugrenue est racontée par la présentatrice : elle a voulu faire quelques tests sur leur chatbot interne et lui a demandé les identifiants de PostgreSQL (sous-entendu par défaut). On pourrait s’attendre à recevoir la réponse de la documentation Postgre … mais non, le RAG a répondu avec de vrais identifiants de l’un de leurs environnements. Comment est-ce possible ? C’est simple, il est branché sur tous leurs documents, y compris la documentation technique interne qui contient ces informations. Nous ne commenterons pas le fait que des mots de passe soient écrits en clair dans des documents.

Solutions Proposées

Peu importe notre contexte, on ne peut pas partir du principe que nos utilisateurs ne risquent pas de fournir des informations confidentielles au chatbot, que ce soit via des documents ou dans le texte de leur prompt. Il faut donc trouver un moyen d'empêcher au chatbot de les recevoir.

La présentatrice nous a donc montré deux librairies python pour le faire : Presidio et LLM Guard.

Presidio

Presidio permet d’analyser et anonymiser un texte. Il détecte les noms, prénoms, identifiants, mots de passe, emails, téléphones. On peut également créer nos propres règles avec des regex, checksums ou NER.

LLM Guard

LLM Guard a été démontré de manière amusante, en parlant de façon légèrement agressive et insultante au modèle qui nous montre avoir remarqué les insultes et les avoir censurés. Il est aussi capable de détecter les injections de prompt et les empêcher.

Conclusion

La démo finale nous a montré ce que l’utilisateur envoie, ce que la librairie a extrait comme informations et ce que le LLM voit. Si on demande au chatbot de répéter ce qu’on vient de lui dire, on voit que les informations confidentielles sont censurées car elles n’ont en réalité jamais atteint le LLM.

En conclusion, il est possible et essentiel de protéger les données à l'ère de l'IA en utilisant des outils appropriés pour éviter les fuites de données et garantir la confidentialité des informations.

La santé a-t-elle peur du cloud ?

Tanoh N’GOYET
Conférence présentée par Montaine MARTEAU, Co-fondatrice et Fractional CPTO chez bttrways.

TL;DR

• Le RGPD n’empêche pas le traitement des données de santé, il pose plutôt un cadre pour leur traitement.
• La donnée de santé ne se vend pas plus cher qu’une autre sur le dark web, toutefois sa compromission peut avoir de lourdes conséquences.
• La santé n’a pas peur du cloud, elle a besoin d’un cloud qui satisfait à ses exigences.

Le traitement des données de santé

Le RGPD (Règlement Général de Protection des Données) autorise le traitement des données de santé pour différents motifs tels que l’intérêt public ou la recherche scientifique. Toutefois, ce traitement n’est possible qu’à certaines conditions.

En France, ces conditions sont posées par la CNIL qui a mis en place une méthodologie de référence appelée la MR-004. Cette méthodologie stipule que tout organisme qui désire mener des travaux de recherche sur des données de santé doit s’engager auprès de la CNIL via un contrat qui indique les règles à respecter pour le traitement des données de santé. Cette déclaration est à effectuer une seule fois auprès de la CNIL, ensuite l’organisme peut mener autant de projets de recherche qu’il le désire sur des données de santé.

Plus concrètement, dans sa déclaration à la CNIL, l’organisme de recherche s’engage à des actions telles que :

• Ne pas conserver les données plus de 2 ans après la publication des résultats ou la fin de l’étude.
• Collecter uniquement les données dont il a besoin.
• Garder autant que possible les données en internes à l’UE; s’il faut les sortir de l’UE, cela doit être justifié.
• Respecter le droit des patients, c’est-à-dire :
  • Informer les patients de la finalité de la recherche.
  • Pseudonymiser les données c’est-à-dire remplacer l’identifiant du patient par un pseudonyme. A noter, le RGPD n’impose pas d’anonymiser les données personnelles.
  • Sécuriser les données des patients.
  • Tenir compte du droit à l’opposition des patients : le consentement du patient est explicite dès lors que le patient est informé qu’il sera inclus dans un projet de recherche. Le patient dispose toutefois d’un droit à l’opposition s’il ne désire pas y être inclus.

Le RGPD n’empêche donc pas le traitement des données de santé, il pose plutôt un cadre pour leur traitement. La CNIL, pour sa part, agit comme un régulateur : elle peut contrôler les organismes de recherche et sanctionner ceux qui ne respectent pas le RGPD. Les deux plus grosses sanctions qu’elle a infligées ces dernières années sont celles relatives aux sociétés Dedalus Biologie en 2022 et Cegedim Santé en 2024 condamnées respectivement à 1,5 millions d’euros et 800 000 euros d’amende.

L’hébergement des données de santé

Les données de santé ont plusieurs particularités, parmi lesquelles : 

• Elles sont sensibles, par conséquent, leur traitement ne doit pas être effectué à la légère.
• Elles peuvent être non structurées (par exemple des données écrites dans des champs de texte libre tels que les comptes rendus des médecins), ce qui ne facilite pas leur exploitation.
• Leur harmonisation est fastidieuse car les logiciels métiers divergent d’un hôpital à un autre ou à l’intérieur d’un même hôpital.

Un hôpital peut choisir d’héberger les données de santé de ses patients en local ou dans le cloud. Ce choix a plusieurs implications :

• Si l’hôpital héberge les données de santé en local, cela ne pose pas de problème en matière de souveraineté des données.
• Si l'hôpital désire héberger les données de santé dans le cloud, il lui faut obligatoirement un hébergeur certifié HDS (Hébergeur de Données de Santé). La certification HDS comporte 6 niveaux, toutefois il n’est pas obligatoire pour un hébergeur certifié HDS de valider l’ensemble des 6 niveaux de certification.
  La grande majorité des hébergeurs certifiés HDS ont leur siège social en France (ex : Orange, OVH, etc.). D’autres tels que AWS, Google, Microsoft, etc., ont leur siège social situé aux Etats-Unis. Le problème avec ces derniers est qu’ils sont soumis au CLOUD Act, ce qui autorise dans certains cas les Etats-Unis à accéder aux données qu’ils hébergent et ce, peu importe le pays dans lequel ces données sont hébergées.
  Le choix de l’hébergeur HDS est donc stratégique car il a des conséquences importantes sur l’accès aux données. Un exemple pratique est celui du HDH (Health Data Hub), un organisme français créé pour faciliter l’accès aux données de santé de manière sécurisée. Le HDH est basé sur le SNDS (Système National des Données de Santé) qui est l’une des bases de données de santé les plus importantes du monde.
  Le HDH est hébergé sur Microsoft Azure. Le choix de Microsoft comme hébergeur a suscité une polémique et la CNIL a émis des réserves sur ce choix d’un hébergeur américain. Une migration hors du cloud de Microsoft a été prévue pour 2026, toutefois à ce jour, les travaux de migration ne semblent pas avoir beaucoup avancé.
• Si l'hôpital désire héberger les données de santé en local tout en profitant de la puissance du cloud pour effectuer des traitements à base d’intelligence artificielle, une alternative intéressante au “tout cloud” peut être de mettre en place une solution d’apprentissage fédéré. Cela consiste à entraîner des modèles de machine learning sur des nœuds hébergés en local et avec des données locales sans qu’il soit nécessaire d’échanger les données entre les nœuds ou de centraliser les données sur un serveur hébergé dans le cloud par exemple. L’un des premiers projets en France à bénéficier de l’apprentissage fédéré est le projet MELLODY relatif à la recherche sur le cancer.

La sécurisation des données de santé

La donnée de santé est vitale car sa compromission peut avoir des conséquences graves sur la vie des patients. En effet, une cyberattaque visant un hôpital peut perturber gravement l’accès aux soins des patients. A ce titre, l’on peut citer la cyberattaque subie par le Centre Hospitalier de Dax.

Toutefois, il est important de noter qu’il n’y a pas plus de cyberattaques dans la santé qu’ailleurs. Les cyberattaques dans le domaine de la santé sont plus médiatisées mais elles sont beaucoup moins fréquentes que celles qui visent les entreprises. Le secteur de la santé est le troisième secteur le plus touché par les cyberattaques, après les collectivités territoriales et les TPE/PME, selon l’ANSSI.

La donnée de santé est rare mais elle ne vaut pas plus cher sur le dark web que les autres données, sauf s’il s’agit de données de santé de personnes publiques par exemple.

Conclusion

L’on pourrait opposer la tech et la santé, en arguant que le monde de la tech est rapide, agile et scalable tandis que celui de la santé est lent, rigide, trop rigoureux. Cependant, il ne faut pas opposer ces deux mondes car en les faisant travailler ensemble, il est possible de trouver des solutions utiles, concrètes, respectueuses des besoins des personnels de santé et de la réglementation.

La santé n’a donc pas peur du cloud, elle a plutôt besoin d’un cloud qui réponde à ses exigences.