Quatre mois sur OCHA RAG, le système d'IA que la cellule Évaluation et analyse d'OCHA utilise pour rédiger des analyses de situation à partir des informations produites par une crise. Je l'ai utilisé lors de trois séismes, puis j'ai transformé ce qui ne fonctionnait pas sur le terrain en améliorations testées du produit.
Contexte
UN OCHA HPCS, cellule Évaluation et analyse, Genève
J'ai travaillé avec le développeur principal de la cellule sur trois versions du système : un pipeline Python en ligne de commande construit pour chaque événement, une interface web déployée sur Azure, et le service actuel en Rust, avec un graphe de connaissances, une recherche vectorielle et une console web.
Chaque urgence a servi de test en conditions réelles. Pendant la réponse, je faisais tourner l'outil et livrais ce dont le bureau avait besoin ; ensuite, je corrigeais la cause du problème dans le produit. Trois règles ont guidé le travail : reproduire un défaut sur des données réelles avant d'en nommer la cause, vérifier que chaque nouveau contrôle peut réellement échouer, et intégrer chaque modification par une pull request relue.
Réponses aux urgences
Juin 2026Philippines · M7,8
Des chiffres officiels derrière un CAPTCHA
Problème. Les bulletins de l'agence nationale de gestion des catastrophes, source des chiffres sur les victimes, étaient protégés par Cloudflare et un CAPTCHA.
Solution. Une collecte par navigateur automatisé, avec des pilotes locaux pour les réseaux restreints, puis le passage à des sites miroirs.
Impact : les chiffres nationaux officiels ont alimenté le pipeline de rapports pendant la réponse.
Juin–juil. 2026Venezuela
Le CLI RAG et une interface web en production
Problème. Les analystes avaient besoin de rapports en quelques heures, avec un pipeline qu'il fallait lancer à la main.
Solution. Déploiement d'une interface web sur Azure, recherche d'actualités ancrée sur l'événement, vérification des chiffres auprès de sources de référence, et modèles pour les analyses par cluster et l'évaluation des besoins.
Impact : 4 éditions d'analyse de situation, 3 analyses par cluster et une évaluation des besoins en deux semaines ; bureaux pays formés à son utilisation.
Août 2026Colombie · M7,4
Villages ruraux difficiles d'accès
Problème. Les bilans couvraient les villes ; les hameaux ruraux dispersés restaient invisibles. Le bureau avait aussi besoin d'analyses prêtes pour les clusters.
Solution. Appui à la coordination et notes par cluster pour le bureau pays ; croisement de la grille d'intensité ShakeMap avec chaque centre habité de six départements.
Impact : 271 localités rurales à intensité VII–VIII signalées, dont 34 dans le Chocó, pour planifier l'accès.
Août 2026Colombie · tableau de bord
Carte satellite des incendies de la NASA
Problème. Le tableau de bord de la réponse ne montrait pas l'activité des incendies autour de l'épicentre.
Solution. Les détections d'incendies actifs NASA FIRMS superposées aux zones de secousse, avec un récit où chaque chiffre vient des données, jamais du modèle.
Impact : les détections sont passées de 47 par jour avant le séisme à 351 le jour du séisme.
Améliorations : plateforme, ingestion et requêtes
Nettoyage et ingestion sous charge. Les envois groupés saturaient la base de données et le code mort s'accumulait. Écritures groupées et envoi en une seule requête ; 256 695 lignes mortes supprimées.
Collecte et géographie fiabilisées. Les rapports composés uniquement de PDF échouaient définitivement et des chiffres départementaux étaient classés comme nationaux. Pièces jointes conservées, lieux résolus du niveau le plus fin au plus large, et un service qui identifie un même événement dans USGS, GDACS et WFP ADAM.
Réponses multilingues. Les questions en espagnol et en bahasa contournaient la logique des chiffres actuels. Même traitement dans les trois langues, et les questions nationales reçoivent le chiffre national.
Dates de publication. Aucun des 95 PDF téléversés à la main n'était daté, ce qui cachait 28 % du corpus aux filtres par date. Les dates sont désormais trouvées à l'ingestion et ajoutées au corpus existant, et la recherche peut être limitée à une période.
Isolation des espaces de travail. Trois services du graphe pouvaient renvoyer les données d'un autre espace de travail. Une règle commune a fermé cette faille.
Mesurer avant de construire. Une expérience sur 72 requêtes a montré qu'une recherche limitée par lieu ferait chuter la pertinence de 90 % à 52 % ; l'idée a donc été abandonnée au lieu d'être construite.
Le module de rapports
Environ six des seize semaines y ont été consacrées. L'objectif : un rapport qu'un analyste peut valider, rédigé en prose, limité à une zone, avec chaque chiffre fondé sur une source et chaque affirmation citée.
Des rapports en prose. Modèles avec une question centrale, des objectifs par section et des consignes de rédaction ; un corpus en espagnol fonde à nouveau ses chiffres ; les chiffres de contexte n'entrent plus dans un rapport sur un séisme.
Choix de la zone administrative. Une analyse se limite à un pays, un département et une municipalité choisis dans les limites officielles, et le rapport reste dans la zone choisie.
Export Word et modèles personnalisés. Les rapports se téléchargent au format Word d'OCHA, et les cellules de crise conçoivent leur propre structure de rapport sans modifier le code.
Citations. Enregistrées comme des données plutôt que laissées au modèle, renumérotées dans l'ordre de lecture, conservées lors de la relecture automatique (6 tests sur 6 ont gardé chaque marqueur), une infobulle par affirmation.
Vérification des chiffres. Un onglet Chiffres où une personne valide, retire ou ajoute un chiffre. Un chiffre validé devient celui du rapport partout, et les autres valeurs signalées restent visibles.
Fiabilité du contrôle numérique. Fin des échecs d'analyse complets causés par des dates écrites sans séparateurs, et chaque jugement écarté est désormais journalisé avec sa raison.
La règle derrière tout cela : une personne décide des chiffres, le moteur montre ses sources. Un modèle ne fait jamais la moyenne ni la somme de chiffres issus de sources différentes ; un chiffre validé tranche, et l'éventail des valeurs reste visible.
La suite
Un registre unique des indicateurs. Le vocabulaire des indicateurs est tenu à la main à sept endroits. Un registre unique devrait déclarer, pour chaque indicateur, son type, s'il peut être additionné entre lieux, et sa norme de référence (Sendai, HXL, JIAF), avec un test qui échoue dès que le code émet un indicateur non déclaré.
Qualité du registre des chiffres. Indiquer à quel événement appartient chaque chiffre, choisir un chiffre principal quand aucun n'est validé, et suivre l'origine d'un chiffre pour qu'une reprise ne compte pas comme une deuxième source.
Activer ou supprimer les règles inutilisées. Les règles d'inférence entre impacts et besoins ne se sont jamais déclenchées ; il faut les connecter ou les supprimer.
Pour toute question sur OCHA RAG ou sur l'IA au service de l'analyse humanitaire, contactez-moi.
Cette page décrit ma propre contribution dans les grandes lignes. Elle ne représente pas les positions officielles des Nations Unies, et aucune donnée, aucun code ni document interne n'est partagé.