Salif Sawadogo

• Scoring spécifique au RAG : exactitude et similarité de la réponse, pertinence, fidélité (le taux d'hallucination), précision et rappel contextuels. Récupération et génération notées séparément, parce qu'elles échouent pour des raisons différentes et que le correctif n'est jamais le même.
• Contrôles déterministes à côté du juge : faits clés obligatoires et assertions de présence. Certaines choses ne se notent pas sur une échelle de 10. Soit elles sont là, soit la réponse est fausse.
• LLM-as-judge fait sérieusement : comparaison par paires avec majorité sur 3 votes, ordre de présentation randomisé pour éliminer le biais de position, grilles calibrées pour la fidélité, l'utilité et la sûreté.
• Jeux de données de référence construits avec le métier, pas par le modèle. Les données synthétiques détectent l'instabilité technique à grande échelle, mais ne captent ni la nuance ni les références réglementaires que porte un expert du domaine. Chaque cas a besoin de trois parties : la question formulée comme un utilisateur la poserait vraiment, la réponse qu'un expert écrirait, et le document source qui la prouve. Plus les tests négatifs : les questions que le système doit refuser.
• Définition et application de SLI/SLO, avec des portes de livraison qui bloquent une mise en production dès qu'un chiffre passe sous la cible.
• Traçage et supervision : traces Langfuse par requête, streaming au niveau du token, visualisation des appels d'outils pour les flux multi-agents.
• Détection de dérive : Kolmogorov-Smirnov et Population Stability Index, avec alerting configurable.
• Évaluation multilingue là où exact match et F1 s'effondrent : BLEU, METEOR, TER, chrF.
• La rigueur statistique que la plupart des travaux d'évaluation sautent : analyse de puissance avant le test, intervalles de confiance par bootstrap, McNemar pour les résultats binaires appariés, alpha-spending pour empêcher une équipe d'aller chercher un faux positif à force de regarder les résultats en cours de route.

Mission type : vous avez un système RAG ou agentique en production et aucune idée de si le changement de prompt de la semaine dernière l'a amélioré ou dégradé. Je vous livre une suite d'évaluation notée, un tableau de bord, et une porte de livraison. Deux à quatre semaines.

• Recherche hybride : BM25 plus embeddings denses, avec reranking. Bases vectorielles dont Azure AI Search, LanceDB et pgvector.
• Ingestion documentaire à l'échelle : crawling, parsing Docling, stratégies de découpage, métadonnées et récupération par section via fil d'Ariane.
• Orchestration d'agents avec LangGraph, pydantic-ai, LangChain, et intégration d'outils MCP.
• Harnais d'agents et appel d'outils. Le framework est la partie facile. C'est le harnais qui décide si un agent est utilisable en production : contrats d'outils typés pour qu'un appel malformé échoue à la frontière plutôt que trois étapes plus loin, surfaces d'outils délimitées par cas d'usage plutôt que de tout donner à chaque agent, terminaison explicite et budgets d'étapes pour qu'une boucle ne fasse pas exploser la facture, comportement de reprise et de repli quand un outil échoue ou ne renvoie rien, et journalisation par tour qui rend une mauvaise trajectoire lisible après coup. Model Context Protocol quand les outils doivent être partagés entre systèmes.
• Routage multi-agents : verrous structurels pour les chemins déterministes, routeurs LLM pour les chemins sémantiques, avec des replis quand une branche remonte trop peu de contexte.
• Patterns de passerelle LLM : une seule couche de routage pour que les applications ne codent jamais en dur le SDK d'un fournisseur, ce qui fait du changement de modèle et du contrôle des coûts une affaire de configuration.

Mission type : vos réponses RAG sont plausibles mais fausses, ou votre agent boucle. J'audite la qualité de récupération séparément de la qualité de génération, je corrige la couche qui échoue réellement, et je vous laisse la suite d'évaluation qui le prouve.

• CI/CD avec portes de validation automatisées : qualité du code, validation du modèle contre des jeux de référence, compatibilité d'infrastructure, analyse des dépendances.
• MLflow Model Registry avec promotion de staging vers production, portes d'approbation, traçabilité de lignage, et retour arrière vers n'importe quelle version antérieure.
• Déploiement blue-green et canary, trafic miroir, retour arrière automatique en cas de violation de SLO.
• Kubernetes (AWS EKS), Docker, Terraform, Azure Container Apps, inférence GPU serverless.
• Architecture offline-first : lectures cache-first IndexedDB et SQLite, files de mutations, rejeu automatique à la reconnexion, chiffrement AES-GCM au repos.
• Inférence sur l'appareil : modèles de parole et de langage quantifiés tournant entièrement sur du matériel Android de milieu de gamme, mesurés sur les téléphones que les gens possèdent vraiment plutôt que sur un flagship. Zéro réseau, zéro coût par requête, rien qui quitte l'appareil.
• Privacy by design : pipelines conformes RGPD, chiffrement des données de santé, isolation multi-tenant appliquée au niveau de la base, modélisation du consentement avec portée et expiration.

Mission type : vous avez besoin d'IA dans un environnement à contraintes réelles (données de santé, réseau isolé, connectivité intermittente, un régulateur). Je conçois l'architecture et le récit de conformité ensemble, parce que greffer le second sur la première après coup ne marche jamais.

Quand la sortie d'un modèle pilote une décision dont l'erreur coûte quelque chose, je rends l'incertitude explicite et calibrée.

• Prédiction conforme, qui enveloppe un modèle déjà entraîné et renvoie des intervalles ou des ensembles de prédiction avec une garantie de couverture à échantillon fini, sans hypothèse de distribution et indépendante du modèle. En régression, variantes localement adaptatives et régression quantile conformalisée, pour que l'intervalle s'élargisse là où le modèle est vraiment incertain au lieu de rester une bande constante. En classification, des ensembles de prédiction plutôt qu'une étiquette unique forcée.
• Juger les intervalles eux-mêmes, pas seulement les produire : couverture marginale contre la cible, largeur moyenne, adaptabilité selon les régimes, et le score de Winkler quand il faut un chiffre unique qui pénalise autant un intervalle trop large pour être utile qu'un intervalle trop étroit pour être honnête.
• Savoir où la garantie s'arrête. La couverture est marginale, pas conditionnelle : 90 pour cent au global peut cacher 60 pour cent sur le sous-groupe qui vous intéresse, d'où le contrôle de couverture par segment. Et le cadre suppose l'échangeabilité, donc il se dégrade sous dérive de distribution et demande une pondération ou un schéma adaptatif quand les données bougent.
• Incertitude classique quand elle convient mieux : intervalles de confiance par bootstrap, estimation sous contraintes pour resserrer les erreurs types quand le signe d'un effet est connu a priori, et analyse de puissance avant l'expérience plutôt qu'après.
• Seuils de décision sensibles au coût. Réglage du point de fonctionnement contre la métrique métier réelle et les coûts d'erreur asymétriques, plutôt que de rester à 0,5 et d'accepter ce que la matrice de confusion veut bien donner.
• Calibration, pour qu'une probabilité prédite de 0,8 signifie que l'événement survient 80 pour cent du temps, ce qui est la condition préalable pour que tout le reste vaille quelque chose.

Mission type : votre modèle est assez juste en moyenne et fait quand même des erreurs coûteuses, parce que rien en aval ne sait quelles prédictions il faut se méfier. J'ajoute la couche d'incertitude et je règle la règle de décision sur votre coût d'erreur réel.

• Géomarketing et analyse de zone de chalandise : modélisation de zone d'attraction, indices spatiaux, enrichissement par points d'intérêt et fréquentation, distance géodésique sur des projections correctes. Répondre à quels points de vente sont comparables, et pourquoi.
• Résolution d'entités et appariement d'enregistrements : rapprochement flou des données clients internes avec des sources externes quand il n'existe aucune clé commune, avec une vérité terrain étiquetée à la main plutôt qu'un seuil de similarité non validé.
• Segmentation client : K-means et classification hiérarchique sur des variables comportementales et spatiales, avec des segments décrits dans le vocabulaire de l'équipe commerciale, plus un classifieur pour affecter les nouveaux comptes.
• Modélisation de la demande et élasticités : spécifications log-log à effets fixes qui donnent directement les élasticités-prix et croisées, avec cannibalisation et effets de halo modélisés explicitement par une matrice de substitution.
• Optimisation d'assortiment et de planogramme : construction de gamme gloutonne ou sous contraintes qui tient compte de la substitution au fur et à mesure que le linéaire se remplit, contre un objectif de volume ou de marge. Rationalisation de SKU sur la même mécanique.
• Prévision des nouveaux produits : modélisation par analogie pour les SKU sans historique, via la similarité dans l'espace des attributs.
• RFM, valeur vie client et attrition : y compris l'analyse de survie quand le métier a besoin de savoir quand, et pas seulement si.
• Prévision de la demande : SARIMAX quand la structure saisonnière est le signal, gradient boosting quand elle ne l'est pas.

Mission type : vous avez des données transactionnelles et une question commerciale (que faut-il référencer, combien ça va se vendre, quels clients valent la peine d'être défendus) et aucune couche analytique entre les deux. Je la construis, et je la rends réexécutable le trimestre suivant plutôt que d'en faire un deck à usage unique.

• Colonne vertébrale : passerelle LiteLLM routant chaque appel LLM de l'organisation, Langfuse pour les traces, MLflow pour le suivi d'expériences. La tarification des modèles est de la configuration, pas du code, donc le contrôle des coûts et le changement de fournisseur ne demandent aucun déploiement.
• L'évaluation comme service mutualisé. C'est la partie dont je suis le plus fier. Plutôt que chaque équipe bot improvise son propre scoring, il y a un seul service FastAPI que tous les assistants appellent : jeux de questions et réponses attendues notés sur l'exactitude, la pertinence, la fidélité, la précision et le rappel contextuels, à côté de contrôles déterministes de faits clés et de présence. Les appels au juge passent par la même passerelle que tout le reste. Les jobs tournent en asynchrone, les résultats atterrissent dans MLflow. Chaque bot de la plateforme livre désormais le même couple standard : un jeu d'évaluation construit avec le métier, puis un score de campagne publié.
• Ingestion : crawler sur le système de gestion documentaire de la banque, parsing Docling, stockage blob plus indexation Azure AI Search. Traite les rapports d'évaluation de projet, les documents de stratégie pays, les rapports d'achèvement et les évaluations thématiques à travers les pays membres, en français et en anglais.
• Assistants : six agents RAG indépendants (qualité des opérations, connaissance SharePoint, économie, opérations non souveraines, résultats d'évaluation, objectifs de développement durable), isolés les uns des autres pour qu'une livraison d'une équipe ne casse pas celle d'une autre, mais tous assis sur un même paquet cœur partagé.
• Un seul framework d'agents, délibérément. Les bots tournent sur pydantic-ai, câblés à la passerelle via un adaptateur de modèle partagé, avec des contrats d'outils typés et un logger de tour commun. Standardiser était une décision, pas un accident : avant cela, chaque bot avait sa propre orchestration, sa propre gestion d'historique et sa propre manière d'échouer. Un assistant reste sur LangGraph parce que son graphe multi-étapes a réellement besoin de transitions d'état explicites, et le forcer à converger aurait coûté plus que ça n'aurait rapporté. Choisir un défaut et documenter l'exception, c'est la partie que la plupart des travaux de plateforme ratent.
• Génération de documents : agents pydantic-ai qui rédigent des notes de concept et notent la maturité d'un projet sur quatre dimensions, avec une architecture routeur plus spécialistes plus synthèse, des verrous structurels pour les routes qui doivent être déterministes et un routeur LLM pour le reste.

Un capteur virtuel pour l'usure des freins d'avion, et un brevet

Vérifier l'usure d'un puits de chaleur de frein d'avion suppose normalement d'envoyer quelqu'un l'inspecter au sol. Nous avons remplacé l'inspection par une estimation : lire les capteurs de température pendant la phase de stationnement après atterrissage, mesurer le temps de refroidissement du frein, et en déduire l'usure.

La difficulté, c'est que le temps de refroidissement n'est pas un signal propre. La température ambiante, le vent et les conditions du tarmac ce jour-là le déplacent tous, si bien que le même frein dans le même état ne se présente pas pareil à Dubaï et à Oslo. La méthode modélise donc l'environnement explicitement, par une régression XGBoost qui prédit comment ces conditions décalent le temps de refroidissement attendu, et lit l'usure dans ce que l'environnement n'explique pas. Le résultat : une surveillance par avion et par frein sur toute une flotte, en continu, sans que personne aille regarder.

Déposé par Safran avec trois inventeurs nommés, dont moi. Priorité française en août 2024, dépôt PCT en juillet 2025, publié sous WO2026032835A1 en février 2026. Contrairement à tout le reste de la partie Safran, celui-ci se lit intégralement : un brevet publié est une divulgation publique par définition, donc la méthode, le choix de modélisation et le raisonnement sont tous dans le document.

IA générative en production

• Chatbot multi-agents construit de zéro sur une couche interne de LLM-as-a-service, avec appel d'outils et intégration MCP.
• Cadre d'évaluation avec objectifs de niveau de service appliqués sur l'exactitude factuelle, la qualité de réponse jugée, la toxicité, l'exposition de données personnelles, la latence et la disponibilité, câblé à des portes de livraison qui bloquaient toute mise en production dès qu'une cible n'était pas atteinte.
• Observabilité multicouche : traces Langfuse, métriques MLflow et Prometheus, tableaux de bord Grafana sur la couche Kubernetes, avec suivi des coûts et alertes de budget.
• Discipline de livraison construite autour de déploiements hebdomadaires, d'un délai court entre commit et production, d'une reprise rapide et d'un faible taux d'échec de changement, le tout mesuré plutôt qu'affirmé.
• Plateforme data science AWS sur EKS, construite pour les exigences de passage à l'échelle et de sécurité de l'équipe.

• Découpé en un service d'évaluation (logique métier, consultations, critères, notes, exports) et un service d'intelligence (extraction, analyse, scoring), communiquant par webhook pour qu'un long job LLM ne bloque jamais une requête.
• Normalisation linguistique avant notation : le texte est extrait, la langue détectée, puis traduite vers une langue de travail unique. Sans cette étape, un CV en français et un CV en anglais sont notés sur des bases différentes, ce qui est le genre de biais que personne ne remarque jusqu'à ce qu'un candidat non retenu demande pourquoi.
• Notation adossée à la recherche documentaire contre les termes de référence, pas à du prompting libre, pour que chaque note remonte à une preuve précise dans le document.
• Server-sent events pour la progression, export Excel, sortie en liste courte classée.

Celui-ci se généralise bien. Tout flux de la forme « noter beaucoup de documents contre une seule grille, et pouvoir justifier chaque note » est le même système.

Le travail de plateforme que je fais chez Safran et à la Banque africaine de développement est sous NDA. Voici la même architecture, ouverte, pour que vous puissiez la lire avant de m'embaucher : github.com/sawallesalfo/DS-backbone

Un seul docker compose up donne à une équipe la boucle complète : JupyterLab pour l'exploration, MLflow pour le suivi d'expériences et le registre de modèles, PostgreSQL comme base de MLflow, MinIO comme stockage d'artefacts et de jeux de données compatible S3, et Nginx qui route le tout derrière des noms d'hôte propres au lieu d'une dispersion de ports localhost.

L'intérêt est dans ce que ça supprime. La plupart des équipes assemblent ces cinq briques à la main, différemment sur chaque poste, puis passent le premier mois d'un projet à comprendre pourquoi une expérience qui tournait en local ne se reproduit pas. La configuration passe par des variables d'environnement, le stockage est compatible S3 dès le premier jour, si bien que passer de ce bac à sable à un vrai stockage cloud est un changement d'URL et pas une réécriture.

Si vous cherchez quelqu'un pour monter votre environnement data ou ML, ce dépôt est le livrable, et vous pouvez l'inspecter avant qu'on se parle.

Le travail le plus complet que je puisse montrer de bout en bout, parce que le rapport est public et l'algorithme cœur aussi.

ECCBC connaissait ses propres points de vente mais ne savait presque rien des quartiers où ils se trouvaient. Chaque point de vente CHR du circuit recevait le même assortiment, parce qu'il n'existait aucune base pour leur en donner de différents. Zones pilotes : Marrakech et Tizi Ouzou. La chaîne se déroule ainsi : enrichir la base clients avec des données spatiales externes, segmenter dessus, modéliser la demande par produit dans chaque segment, puis utiliser ces modèles pour décider ce qui va dans chaque frigo.

• Appariement d'entités sous bruit. Les enregistrements internes n'avaient aucune clé commune avec la moindre source externe. J'ai construit un score de similarité composite sur sept métriques de chaînes (Damerau-Levenshtein, Jaro-Winkler, recouvrement de n-grammes et d'autres), pondéré à 75 pour cent sur le nom, 15 pour cent sur l'adresse, 10 pour cent sur la distance géodésique, avec une recherche dans un rayon de 2 km. Appariement d'un corpus TripAdvisor de 5 457 entrées contre les enregistrements internes. Validé de la manière honnête : un échantillon stratifié de 400 enregistrements vérifié à la main pour produire une vérité terrain étiquetée, puis traité comme un problème supervisé.
• Enrichissement spatial. Analyse de zone de chalandise, indices spatiaux, distance géodésique sur des ellipsoïdes et des projections corrects, plus les signaux OpenStreetMap et Flickr pour la fréquentation et les points d'intérêt.
• Segmentation. K-means avec initialisation K-means++, comparé à la classification hiérarchique, sur variables standardisées. Huit segments interprétables pour les cafés et restaurants, trois pour les hôtels, chacun avec un profil lisible par le métier (Premium et Divertissement, Semi-Rural, Faible Affluence et Mobilité, et ainsi de suite). Les points de vente hors échantillon de clustering ont été affectés par forêt aléatoire.
• Modèles de demande, un par SKU et par segment. Données hebdomadaires, 2019 à 2021, volumes log-transformés avec un effet fixe pour le débit de base, une matrice de cannibalisation entre marques et parfums, et des régresseurs externes pour la météo et les événements. La sélection de variables était automatisée : retirer les variances quasi nulles, retirer les corrélations au-dessus de 0,8 sauf si elles viennent de la matrice de cannibalisation, retirer les VIF au-dessus de 10. Les variables socio-économiques sont tombées d'elles-mêmes, ce qui était le bon résultat : le clustering avait déjà absorbé cette variance, et un modèle qui les gardait aurait compté deux fois.
• Versions sous contraintes et sans contraintes de chaque modèle. La variante contrainte impose des contraintes de signe là où le sens métier est sans ambiguïté : les effets de cannibalisation ne peuvent pas être positifs, les portes de frigo et la qualité du merchandising ne peuvent pas nuire au volume. Cela resserre les erreurs types et les intervalles de confiance, ce qui compte quand la sortie pilote une décision d'achat plutôt qu'une diapositive.
• Validé correctement, à l'échelle. Shapiro-Wilk pour la normalité, White pour l'homoscédasticité, Durbin-Watson pour l'autocorrélation, tous au-dessus de 0,05 sur chaque SKU modélisé. MAE et MAPE calculés après retour hors de l'espace log, parce qu'un terme d'erreur en log ne dit rien à une équipe commerciale. Pire MAPE de test sur l'ensemble des régressions : 14 pour cent. Comme il y avait bien trop de SKU pour les inspecter à la main, le pipeline générait automatiquement un rapport qualité par modèle : statistiques d'ajustement, distributions de coefficients, bornes de contraintes, et résultats des tests d'hypothèse.
• Démarrage à froid sur les nouveaux produits. Un SKU lancé cette année n'a pas d'historique, donc il ne peut pas être modélisé. Plutôt que de l'écarter ou de deviner, je l'ai signalé comme à couverture limitée et estimé par proxy : trouver les trois SKU les plus proches par distance cosinus sur les attributs produit, puis prendre une moyenne pondérée par similarité de leurs prédictions, calibrée sur leurs ventes observées. Les nouveaux produits sont précisément ceux sur lesquels un chef de catégorie veut le plus une réponse.
• L'optimiseur d'assortiment. Construction gloutonne des rangs à partir d'un frigo fictif vide. Le rang 1 est le SKU le plus performant avec la cannibalisation désactivée, puisque rien d'autre n'est encore sur l'étagère. Le rang 2 réestime la cannibalisation contre ce premier produit et choisit le meilleur ajout. Le rang j répète, en conditionnant toujours sur ce qui est déjà dans le frigo. La sortie est un assortiment ordonné par segment, comparé aux rangs réellement observés dans les ventes. La fonction objectif est un paramètre : maximiser le volume, ou maximiser la marge.

La tarification en assurance est un des rares endroits où un modèle doit satisfaire un régulateur autant qu'un métier. J'ai migré la chaîne de tarification des GLM traditionnels vers le machine learning sans perdre cela : modèles de risque de fréquence et de coût séparés, répondant aux exigences réglementaires financières, une migration big data vers Azure avec intégration CI/CD, un traitement conforme RGPD de bout en bout, et un suivi de performance continu après mise en production. Le temps de traitement a baissé de 40 pour cent.

La contrainte intéressante, c'est l'explicabilité. Un actuaire sait défendre un coefficient de GLM devant un superviseur. Le remplacer par un modèle à gradient boosting veut dire que vous devez désormais rendre compte de pourquoi le prix a bougé, ce qui façonne ce que vous avez le droit de construire.

Avant d'y entrer, j'ai gagné la première place du concours interne de data science d'AXA Direct. Le code est public, écrit en R.

Remplacement de la recherche par mots-clés par des embeddings sémantiques à base de BERT, par-dessus une déduplication et une normalisation NLP d'un catalogue produit en désordre.

Puis mesure sérieuse. Pas un split A/B simultané : un déploiement progressif sur quatre semaines, ce qui veut dire que la randomisation était imparfaite et que le chiffre avant-après naïf n'était pas fiable. L'effet a donc été estimé par inférence causale. Causal Forest pour les effets de traitement hétérogènes selon les segments d'utilisateurs, Double Machine Learning pour contrôler les facteurs de confusion, appariement par score de propension pour corriger le biais de sélection introduit par le design du déploiement.

+29 pour cent de satisfaction utilisateur, significatif à p < 0,01, et défendable parce que la dérive saisonnière et comportementale a été modélisée au lieu d'être écartée par hypothèse. Le chiffre que j'aurais annoncé sans cette couche était plus élevé et en partie fictif.

Construit autour de sept questions qu'un détaillant se pose vraiment : qui sont mes meilleurs clients, qui est sur le point de partir, qui pourrait valoir plus qu'aujourd'hui, qui est déjà parti, où l'effort de rétention est rentable, qui est fidèle, et qui répondra à cette campagne. Dépôt public.

• Segmentation RFM comme fondation, parce que récence, fréquence et valeur monétaire sont interprétables par l'équipe commerciale, et qu'une segmentation que personne ne comprend ne sert jamais.
• Valeur vie client modélisée par-dessus.
• Attrition traitée en analyse de survie plutôt qu'en classifieur binaire, pour que la sortie soit quand un client risque de partir, et pas seulement s'il va partir.
• Prévision des ventes à granularité journalière et hebdomadaire, SARIMAX pour la structure saisonnière, XGBoost et LightGBM là où les relations ne sont pas linéaires.
• Suivi des mouvements de supply chain sur la même base de variables.

C'est organisé comme un pipeline (entrées, intermédiaires, puis un dossier par analyse) plutôt qu'en tas de notebooks, ce qui fait la différence entre une analyse que quelqu'un peut relancer le trimestre suivant et une analyse qu'il ne peut pas relancer.

Une association à Ouagadougou qui construit des modèles de parole et de traduction pour une langue sans presque aucun corpus numérique.

• Traduction : NLLB (600M et 1,3B) et Mistral-7B affinés pour le français vers le mooré.
• Reconnaissance vocale : Whisper Large affiné, trois itérations.
• Synthèse vocale : SparkTTS (base Qwen2, LoRA), XTTSv2, VITS, ParlerTTS.
• Classements publics pour la traduction (BLEU, METEOR, chrF), l'ASR (WER, CER) et la TTS, contre un benchmark de 1 483 échantillons sur cinq domaines.
• La partie intéressante : un cercle vertueux de données synthétiques. De la parole réelle entraîne le modèle TTS, le modèle TTS génère de l'audio synthétique qui augmente le corpus ASR, l'ASR amélioré transcrit davantage d'audio réel, ce qui donne plus de paires de textes pour le tour de TTS suivant. C'est ainsi qu'on dépasse un corpus de départ de 1 000 paires sans financer une grande campagne d'enregistrement.

Tout est public : huggingface.co/burkimbia et github.com/BurkimbIA

Plateforme multi-tenant reliant patients, soignants et institutions, conçue pour des régions où voir un spécialiste veut dire voyager et où la connectivité n'est pas garantie.

• Offline-first par conception : les applications patient et soignant fonctionnent sans réseau. Lectures cache-first, mutations mises en file, rejeu automatique à la reconnexion, chiffrement AES-GCM des données de santé au repos dans le navigateur.
• Consentement RGPD à deux niveaux : consentement au stockage, puis consentement d'accès par soignant avec portée et expiration explicites.
• Isolation des tenants appliquée au niveau de la base, avec des utilisateurs pouvant appartenir à plusieurs institutions.
• Service de transcription médicale : ASR en streaming vers des notes cliniques structurées.
• Agent de santé conversationnel avec recherche hybride vectorielle et BM25.

Faire tourner tout l'assistant clinique sur le téléphone. La transcription dans le cloud est la réponse facile et la mauvaise ici : elle demande un réseau que la clinique n'a peut-être pas, et elle envoie la parole du patient à un tiers. J'ai donc construit le chemin hors ligne et je l'ai mesuré. Whisper via whisper.rn pour la parole, un petit modèle de langage via cactus-react-native pour le brouillon de note clinique, mesurés sur les téléphones que les soignants portent réellement (Tecno, Infinix, Samsung série A) plutôt que sur un flagship : Whisper tiny contre small, Gemma 270M contre Qwen3 0,6B, sur la latence et la qualité. Les modèles se téléchargent une fois, ensuite plus rien ne quitte l'appareil.

Ce travail est devenu un guide pas à pas pour déployer un LLM sur mobile, écrit pour des ingénieurs backend et data qui n'ont jamais ouvert Android Studio.

Boutiques et grossistes à Ouagadougou. Le produit n'est pas une caisse enregistreuse, c'est une aide à la décision : marge, tendance, ce qui rapporte vraiment, ce qui dort sur l'étagère. L'analytique est le produit.

Offline-first par nécessité : le SQLite local est la source de vérité, un moteur de synchronisation surveille la connectivité et pousse les ventes en file par lots au retour du réseau. Le multi-tenant est appliqué par la row-level security de Postgres plutôt que par du code applicatif, pour qu'un bug de requête ne puisse pas faire fuiter les ventes d'un commerçant vers un autre.

La couche analytique est là où se trouve le vrai travail, et trois règles la séparent d'un tableau de bord :

• La marge n'est calculée que sur les lignes où le prix d'achat était réellement connu, et chaque chiffre porte son taux de couverture. Une marge présentée comme complète alors qu'elle ignore en silence la moitié des ventes fait décider quelqu'un sur un faux chiffre.
• Une marge inconnue affiche « non calculée », jamais zéro. Une marge nulle et une marge inconnue appellent des actions opposées.
• Le coût est figé au moment de la vente. Les grossistes changent leurs prix sans prévenir. Lire le prix d'achat courant au moment du calcul réécrirait silencieusement les marges du mois dernier.

Pendant la construction, j'ai audité les formules de stock d'un prototype voisin et trouvé que le calcul du délai d'écoulement des stocks divisait une quantité par un montant en devise, utilisait le stock de clôture là où son propre commentaire spécifiait la moyenne, et multipliait par la période après que la division en avait déjà produit une. Sur un cas réel (350 F de prix d'achat, 26 unités de stock moyen, 8 vendues en 14 jours), le prototype renvoyait 0,16 jour contre 45,5 en vrai. L'erreur croissait avec le prix d'achat, ce n'était donc même pas un décalage constant. Le tableau de bord affichait depuis le début des chiffres plausibles et vides de sens.

Les tests sont délibérément démodés ici : 164 tests mobiles tournent contre un vrai moteur SQLite, et 9 tests backend contre un vrai Postgres. J'ai refusé jest-expo parce que ses mocks automatiques n'exécutent aucun SQL, donc la suite passerait sans rien prouver.

Séries mensuelles depuis 2004. Tests de stationnarité (Dickey-Fuller augmenté), cointégration de Johansen, spécification VAR et VECM avec sélection du retard par critère d'information, causalité de Granger, fonctions de réponse impulsionnelle, et décomposition de la variance de l'erreur de prévision à horizon 12 mois. Diagnostics de résidus complets : Jarque-Bera p = 0,38, White p = 0,45, Portmanteau p = 0,91. Incluait une analyse du choc COVID-19 sur le niveau des prix. Diapositives publiques.

Je le mentionne parce que les séries temporelles et l'identification causale reviennent sans arrêt. La prévision, la détection d'anomalies, et toute question de la forme « est-ce notre changement qui a causé ça » relèvent de la même boîte à outils.