Connecter une IA à vos données métier
ne veut pas dire tout lui ouvrir.

Le problème

Une connexion technique donne presque toujours accès à plus de données que nécessaire.

Une clé API, un connecteur ou un agent outillé n'obtient pas un accès calibré sur son besoin réel : il obtient l'accès que la plateforme sait donner. Un assistant chargé de prioriser des relances n'a pas besoin des noms, des adresses, des commentaires internes ni des pièces jointes — il a besoin de délais, de statuts et de tendances. Sans couche intermédiaire, il reçoit tout.

• ! Un connecteur autorisé à lire les tiers lit tous les champs des tiers.
• ! Un agent multi-outils recoupe ce qu'aucun de ses outils n'exposait seul.
• ! Ce qui est sorti une fois vers un service externe ne se rappelle pas.

Le principe Anonari

Donner à l'IA les données dont elle a besoin. Pas toutes celles auxquelles elle pourrait accéder.

Anonari construit une exposition maîtrisée : sélection des champs, minimisation, pseudonymisation, profils par usage, restriction par clé et traçabilité de ce qui a effectivement été exposé. La décision est prise avant la sortie des données, pas laissée au bon vouloir du consommateur.

Pour être clair

Anonari contrôle l'exposition des données. Il ne parle pas à votre IA à votre place.

Anonari ne reçoit pas le prompt final envoyé à un LLM, n'analyse pas vos conversations et ne choisit pas votre fournisseur d'IA — vous gardez la main sur l'usage. Ce qu'Anonari contrôle, c'est la donnée qui sort, pas la conversation que vous construisez ensuite.

Avant / après

La protection intervient avant l'exposition, pas après.

Anonari n'appelle jamais un fournisseur d'IA à votre place : il prépare la donnée, votre application décide de l'usage.

Ce qui reste dans votre plateforme métier

La sélection commence à la source, pas dans notre base.

Pour chaque objet lu, seule une liste de champs explicitement autorisée est retenue. Noms, e-mails, téléphones, adresses complètes, SIRET en clair, notes, champs libres et pièces jointes n'en font jamais partie, ne sont jamais stockés par Anonari et ne sont jamais transmis plus loin.

Séparation des responsabilités

Trois rôles distincts, trois responsabilités distinctes.

Plateformes métier connectables

Anonari n'est pas une couche pour ERP. C'est une couche pour données métier.

Dolibarr et Odoo sont les premières intégrations disponibles, pas le périmètre du produit. Le même mécanisme s'applique à toute plateforme métier exposant une API et capable de fournir une clé d'accès dédiée : e-commerce, CRM, outil de gestion interne.

Une politique par usage

L'application choisit un contexte métier. Anonari applique la politique correspondante.

Une même donnée ne doit pas être exposée de la même façon pour toutes les analyses. Chaque profil détermine les objets accessibles, les catégories autorisées, la précision des dates, la profondeur historique et les transformations appliquées. Ce n'est pas une analyse libre du prompt — c'est une politique fermée, documentée et versionnée, dont l'empreinte est calculée à chaque modification.

Preuve technique du traitement

Un reçu signé pour chaque traitement de minimisation.

Chaque appel à l'endpoint de minimisation retourne un reçu signé cryptographiquement : politique appliquée, version et empreinte de cette politique, catégories retirées, transformées et restituées, nombre de champs en entrée et en sortie, empreinte du résultat.

Périmètre exact : le reçu est émis par l'endpoint de minimisation (POST /api/v1/minimize). Les endpoints de signaux agrégés n'en émettent pas encore. Le reçu atteste le traitement réalisé par Anonari — pas ce que votre application ajoute ensuite au prompt final.

Une clé, un profil

Une clé API est rattachée à un seul profil de données.

Le profil est choisi à la création de la clé et ne peut pas être élargi par la requête. Pour utiliser plusieurs profils, vous créez plusieurs clés distinctes — une par application ou par usage. Une clé compromise n'expose donc que le périmètre d'un seul profil.

Périmètre exact : cette liaison est appliquée par l'endpoint de minimisation. Les endpoints de signaux agrégés, plus anciens, authentifient la clé et son quota mais ne sont pas encore rattachés à un profil — c'est écrit noir sur blanc sur la page Sécurité.

Concrètement

Ce que votre application envoie, ce qu'elle récupère.

Un appel, un profil, une réponse minimisée et son reçu. Le profil vient de la clé : la requête peut seulement déclarer celui qu'elle attend, ce qui provoque un refus en cas d'écart avec la clé utilisée.

{
  "object_type": "customer_invoice_history",
  "expected_profile": "financial.payment-risk.v1",
  "data": {
    "invoice_id": 10472,
    "customer_id": 42,
    "amount_ttc": 3480.00,
    "status": "unpaid",
    "due_date": "2026-08-31",
    "payment_delay_days": 12
  }
}

{
  "trace_id": "trc_9c3e…4b1a",
  "profile": {
    "code": "financial.payment-risk",
    "version": "1",
    "checksum": "7f2b…c9e4"
  },
  "data": {
    "invoice_id": "ref_4d8a1c…",   // pseudonymisé
    "customer_id": "ref_b71e93…",  // pseudonymisé
    "amount_ttc": "1000-5000",      // en tranche
    "status": "unpaid",
    "due_date": -14,             // délai relatif
    "payment_delay_days": 12
  },
  "receipt": {
    "removed_categories": [],
    "transformed_categories": [
      "entity_reference", "financial_amount",
      "calendar_date"
    ],
    "output_digest": "sha256:…",
    "signature": "ed25519:…"
  }
}

Exemple illustratif, aligné sur le contrat réel de l'endpoint. Le socle d'interdictions s'applique en amont : si la charge utile contenait un nom, un e-mail ou une note, l'appel serait refusé — pas nettoyé en silence.

Au-delà de la minimisation

Des signaux calculés ailleurs, restitués sous forme minimisée.

Le calcul des indicateurs n'est pas réalisé par Anonari : il est délégué à une infrastructure de calcul statistique distincte, qui ne reçoit que des données pseudonymisées. Anonari expose le résultat via son API, sous la politique du profil utilisé.

Mise en perspective

Une architecture construite autour de principes que la CNIL met en avant.

Dans ses recommandations sur l'IA et le RGPD, la CNIL demande que les données personnelles utilisées soient « adéquates, pertinentes et limitées à ce qui est nécessaire », et recommande de retenir « le format le moins intrusif sans perte d'information » — une tranche d'âge plutôt qu'une date de naissance complète, par exemple. C'est la mécanique même d'Anonari : montants restitués en tranches, dates généralisées au mois, identifiants remplacés par des pseudonymes.

Recommandations de la CNIL sur le développement des systèmes d'IA ↗
Fiche CNIL — protection des données dans la conception du système ↗

Ce qu'Anonari ne prétend pas faire

Les limites, sans détour.

• ✕ Anonari ne reçoit pas le prompt final destiné au LLM et n'analyse pas vos conversations.
• ✕ Anonari ne contacte pas Claude, ChatGPT ou un autre fournisseur, et ne choisit pas votre fournisseur d'IA.
• ✕ Anonari ne garantit pas ce que votre application ajoute aux données après son traitement.
• ✕ Anonari ne garantit pas la conformité générale de votre traitement et ne remplace pas votre responsable de traitement ou votre DPO.
• ✕ Anonari ne réalise pas d'anonymisation irréversible : les données restituées restent reliées à des identifiants techniques, réassociables dans votre plateforme source. C'est de la minimisation et de la pseudonymisation.
• ✕ Anonari ne calcule pas les statistiques mutualisées : ce calcul appartient à une infrastructure distincte.