Analyser des données sans les centraliser

Pourquoi rassemble-t-on les données au départ

Pour une bonne raison : un modèle apprend mieux quand il voit plus de cas. Une usine qui n'a connu que quelques dizaines de pannes n'a pas de quoi apprendre à les anticiper. Un établissement de santé voit assez de cas pour soigner, rarement assez pour qu'un modèle repère les situations rares. Un établissement bancaire découvre un schéma de fraude que le suivant n'a jamais vu.

La réponse historique a été de tout réunir au même endroit, dans un entrepôt analytique ou un lac de données. Elle fonctionne, et elle crée en même temps un point de convergence, qui concentre les données et les accès aux systèmes dont elles proviennent. Ce point est devenu le chemin de plusieurs fuites françaises en 2026, documenté par les organisations touchées elles-mêmes : voir la fuite vient de la copie.

Et dans beaucoup de situations, le rassemblement n'est même pas possible. Deux concurrents ne s'échangent pas leurs relevés d'atelier. Un sous-traitant ne montre pas ses coûts à son donneur d'ordre. Un hôpital ne sort pas ses dossiers patients. Le projet s'arrête là, pas pour une raison technique.

Déplacer le calcul plutôt que les données

L'alternative inverse la circulation. Au lieu d'amener les données vers le calcul, on amène le calcul vers les données.

• Le modèle commun est envoyé à chaque participant.
• Chacun l'entraîne sur sa propre infrastructure, sur ses propres enregistrements, qui ne bougent pas.
• Seule la mise à jour des paramètres repart, chiffrée de bout en bout.
• Un coordinateur agrège ces mises à jour pour produire une nouvelle version du modèle, que chacun récupère.
• On recommence, tour après tour, jusqu'à ce que le modèle cesse de progresser.

Au bout du compte, chaque participant dispose d'un modèle qui a appris de l'ensemble des données, sans qu'aucun enregistrement ait changé de mains. C'est le principe de l'apprentissage fédéré, et il fonctionne aussi bien entre les sites d'une même entreprise qu'entre organisations distinctes.

Ce qui circule, ce sont des paramètres, jamais des enregistrements. Le transport est chiffré de bout en bout, avec RSA-OAEP 2048 pour l'échange de clé et AES-GCM 256 pour le contenu. Mesh ne calcule pas sur des données chiffrées : le participant déchiffre le modèle avant de l'entraîner, le coordinateur déchiffre les mises à jour avant de les moyenner. L'exécution en enclave et les renforts avancés se proposent en option.

Ce que ça change sur la surface d'exposition

Cette architecture ne réduit pas la probabilité qu'une brique logicielle soit vulnérable. Un outil non corrigé reste exploitable, un identifiant volé reste utilisable, chaque site reste à protéger comme avant.

Ce qu'elle change, c'est ce qui est atteignable quand une brique tombe. Une intrusion chez un participant atteint les données de ce participant, pas celles des autres, parce qu'il n'existe nulle part d'endroit où elles auraient été réunies. Il n'y a pas de copie rassemblée à exfiltrer, et pas d'instance centrale qui détiendrait les identifiants de toutes les bases du périmètre.

C'est aussi la lecture du RGPD sur la minimisation : les données qu'on ne copie pas sont des données qu'on n'a pas à protéger ailleurs, ni à notifier ailleurs.

Ce que ça ne remplace pas

L'apprentissage fédéré couvre l'entraînement de modèles sur des données réparties. Il ne couvre pas tout.

• L'exploration ad hoc, quand un analyste doit lire les enregistrements ligne à ligne pour comprendre une anomalie, demande toujours un accès direct.
• Le reporting réglementaire et le pilotage opérationnel gardent leurs outils et leurs chaînes existantes.
• La qualité et la cohérence des données restent un travail de fond, et la répartition la rend plus exigeante, pas moins : il faut s'accorder sur un vocabulaire commun entre participants.

La question utile n'est donc pas de supprimer tout entrepôt. Elle est de regarder, usage par usage, lesquels n'exigeaient pas la copie qu'on a construite pour eux.

Quand ça vaut le coup

Trois configurations reviennent.

Plusieurs sites d'une même organisation, dont chacun a trop peu d'historique pour entraîner seul un modèle utile, et dont le regroupement poserait un problème de souveraineté, de contrat ou de volume de transfert.

Plusieurs organisations qui ont le même problème et ne peuvent pas s'ouvrir, parce qu'elles sont concurrentes, ou parce que la donnée est couverte par le secret des affaires ou par un régime de protection particulier.

Une chaîne de valeur où chaque acteur ne voit que son maillon, et où la grandeur recherchée dépend de tous les maillons.

À l'inverse, si les données sont déjà réunies légitimement, chez un seul détenteur et sans contrainte de partage, l'apprentissage fédéré ajoute de la complexité sans apporter de gain.

Comment ça se met en place

Le déroulement d'un projet détaille les étapes et la structure des coûts. L'ordre habituel : cadrer la question à laquelle le modèle doit répondre, vérifier que chaque participant dispose des variables nécessaires, s'accorder sur un vocabulaire commun, puis lancer un premier cycle d'entraînement sur un périmètre réduit avant d'élargir.

Une démonstration sur données publiques réelles montre le mécanisme à l'œuvre sur des jeux de données ouverts et cités, avec leur source et leur licence.

Mesh est en phase de lancement. Aucun déploiement en production n'existe à ce jour, et la démonstration simule les participants dans un seul processus. Le calculateur de ROI donne un ordre de grandeur du gain attendu selon le nombre de participants.