Apisphère est en train de devenir bien davantage qu’un site internet.

Autour de gdsa43.fr, le GDSA43 développe progressivement un véritable système d’information sanitaire : adhésions, identité des apiculteurs, registre sanitaire, visites TSA, Programme Sanitaire d’Élevage, précommandes, réseau frelon, campagnes de piégeage, cartographie, documentation et outils destinés au Bureau.

Le portail public montre déjà cette évolution : certaines informations sont accessibles à tous, tandis que d’autres services sont réservés aux adhérents ou aux personnes habilitées. Le registre sanitaire, par exemple, nécessite une authentification, tandis que le Guide du portail distingue déjà plusieurs profils : adhérent, TSA, référent frelon et membre du Bureau ou du conseil d’administration.

Cette évolution fait apparaître une question qui devient centrale :

comment être certain que la personne connectée est bien celle qu’elle prétend être, et comment lui donner exactement les droits correspondant à sa fonction ?

C’est ici qu’intervient la notion de Cloud Identity, ou identité numérique centralisée.

---

De l’identifiant à l’identité

Un site WordPress classique fonctionne généralement avec un principe simple :

adresse électronique + mot de passe = compte utilisateur.

Cela suffit pour publier un commentaire ou accéder à un espace personnel relativement simple.

Mais Apisphère doit progressivement gérer des situations beaucoup plus complexes.

Une même personne peut être :

• adhérente du GDSA43 ;
• apicultrice avec un NAPI ;
• Technicien Sanitaire Apicole ;
• référente frelon ;
• membre du conseil d’administration ;
• membre du Bureau ;
• responsable d’une fonction particulière.

Et ces qualités ne donnent évidemment pas accès aux mêmes informations.

Le vétérinaire-conseil n’a pas besoin d’accéder à l’administration WordPress.

Un référent frelon n’a aucune raison de consulter les opérations comptables.

Un trésorier n’a pas nécessairement à connaître le détail des observations sanitaires d’un rucher.

Un TSA doit pouvoir travailler sur les dossiers qui lui sont confiés sans disposer pour autant des pouvoirs du secrétaire ou du président.

L’enjeu n’est donc plus simplement de créer des comptes.

Il devient nécessaire de gérer des identités, des fonctions, des habilitations et leur cycle de vie.

---

Qu’est-ce que Cloud Identity ?

Cloud Identity est une solution de gestion centralisée des identités et des accès, appartenant à la famille des systèmes IDaaS — Identity as a Service.

Dans le cas de Google Cloud Identity, la plateforme permet notamment de centraliser utilisateurs et groupes, de mettre en œuvre l’authentification multifacteur, le Single Sign-On (SSO), certaines politiques relatives aux appareils et l’accès à des applications tierces. Google propose une édition gratuite et une édition Premium.

L’idée fondamentale est simple :

l’application n’a plus nécessairement à décider seule si une personne est bien celle qu’elle prétend être.

Elle peut s’appuyer sur un fournisseur d’identité.

Des standards comme OpenID Connect (OIDC) ou SAML 2.0 permettent ensuite de transmettre cette identité aux applications autorisées. Google prend notamment en charge ces mécanismes de fédération.

Mais, pour Apisphère, il faut distinguer deux choses.

Le Core Identité Apisphère

Il répond à la question :

« Qui est cette personne dans l’écosystème du GDSA43 ? »

Il peut connaître :

• son identifiant interne ;
• son nom et son prénom ;
• son NAPI ;
• son statut d’adhérent ;
• ses coordonnées ;
• sa commune de rattachement ;
• ses fonctions ;
• son historique ;
• ses mandats ;
• ses relations avec les services sanitaires.

L’adresse électronique n’est d’ailleurs déjà plus considérée dans Apisphère comme le pivot métier de l’identité. Le formulaire d’adhésion précise qu’elle sert au compte et aux confirmations, tandis que l’identifiant adhérent existant est repris après paiement lorsqu’il existe déjà.

La couche Cloud Identity

Elle répond à une autre question :

« Puis-je faire confiance à la personne qui vient de s’authentifier ? »

Puis :

« À quels services cette identité peut-elle accéder ? »

Les deux systèmes sont donc complémentaires.

---

Ce que cela pourrait changer concrètement

Imaginons plusieurs situations.

Simulation 1 — Un adhérent consulte son registre sanitaire

Jean Dupont possède le NAPI FR43001234.

Dans le Core Identité :

Personne #1842
Jean Dupont
NAPI : FR43001234
Adhésion 2027 : valide
Statut : apiculteur

Jean ouvre gdsa43.fr et demande :

Mon registre sanitaire

Apisphère vérifie son authentification.

Une fois son identité confirmée :

Identité reconnue : #1842
Profil : adhérent
Registre demandé : propriétaire #1842

Accès autorisé.

Jean ne peut consulter que son propre registre.

Ce fonctionnement correspond à la logique déjà affichée par le portail, où les données individuelles et observations sanitaires sont réservées à l’adhérent concerné et aux personnes habilitées.

---

Simulation 2 — Le même utilisateur devient TSA

Quelques mois plus tard, Jean devient Technicien Sanitaire Apicole.

Il n’est pas nécessaire de lui fabriquer une seconde identité.

Son identité reste :

Personne #1842

mais Apisphère lui associe désormais une habilitation :

TSA — actif

Lorsqu’il ouvre son espace :

Tableau de bord Jean Dupont

Apisphère pourrait lui présenter :

Mon espace adhérent
Mon registre sanitaire
Mes ruchers
Mes visites TSA à réaliser

En entrant dans la partie TSA, ses permissions changent.

Il peut consulter les dossiers qui lui sont affectés.

Il ne devient pas administrateur du système.

---

Simulation 3 — Un référent frelon

Marie Martin est référente pour trois communes.

Son identité est authentifiée.

Apisphère connaît parallèlement ses habilitations territoriales :

Référente frelon

Communes autorisées :

• Tence ;
• Chenereilles ;
• Le Mas-de-Tence.

Elle consulte la campagne de piégeage.

Apisphère lui montre les signalements correspondant à son territoire.

Un signalement concernant Yssingeaux apparaît ?

Accès refusé : territoire hors habilitation.

Ce n’est donc plus seulement un système de rôles.

C’est potentiellement un système :

identité + fonction + territoire + campagne + période de validité.

---

Simulation 4 — Changement de trésorier

Voilà un cas où la gestion centralisée des identités devient particulièrement intéressante.

Paul est trésorier jusqu’au 14 février 2028.

Le 15 février, Sophie lui succède.

Dans un système classique, il faut parfois penser à modifier plusieurs comptes et plusieurs extensions.

Avec une gestion centralisée :

Paul Martin

role_tresorier = expiré

Sophie Bernard

role_tresorier = actif

À sa prochaine connexion, Paul conserve éventuellement son espace adhérent mais perd automatiquement les outils financiers du Bureau.

Sophie les obtient.

L’accès suit la fonction, pas la personne.

---

Simulation 5 — Une opération sensible

Le trésorier veut exporter la liste complète des règlements.

L’action est plus sensible qu’une simple consultation.

Apisphère pourrait demander une authentification renforcée :

Cette opération nécessite une vérification supplémentaire.

Validation par application d’authentification, clé de sécurité ou autre second facteur.

Après validation :

Identité confirmée — niveau renforcé

L’export est autorisé et journalisé :

21/10/2027 — 18:42
Utilisateur : Sophie Bernard
Fonction : trésorière
Action : export règlements 2027
Authentification renforcée : oui

L’intérêt n’est pas seulement de bloquer les intrus.

Il est aussi de pouvoir répondre à la question :

qui a fait quoi ?

---

Simulation 6 — Un ordinateur inconnu

Un membre du Bureau travaille habituellement depuis son ordinateur.

Une connexion intervient soudainement depuis un nouvel appareil.

Selon l’architecture retenue et le niveau de service utilisé, des règles supplémentaires peuvent être appliquées : authentification multifacteur, contrôle de session ou politiques relatives aux terminaux. La gestion des appareils et l’authentification multifacteur font partie des capacités proposées par Cloud Identity, avec des différences entre éditions.

Pour Apisphère, cela pourrait se traduire par une politique simple :

consultation publique : aucune contrainte particulière

espace adhérent : authentification normale

TSA / référent : authentification renforcée

Bureau / administration : MFA obligatoire

opération particulièrement sensible : nouvelle vérification

Tous les accès ne nécessitent pas le même niveau de sécurité.

---

Simulation 7 — Un bénévole quitte ses fonctions

C’est probablement l’un des cas les plus importants.

Lorsqu’une personne quitte le Bureau, elle ne devrait pas conserver pendant trois ans un compte oublié donnant accès à des informations sensibles.

Son identité peut rester dans le Core Identité :

ancien membre du Bureau

Son historique doit même être conservé lorsque cela est nécessaire.

Mais son habilitation devient :

Bureau : terminée le 31/12/2027

Conséquence immédiate :

accès Bureau : refusé.

On distingue ainsi clairement :

l’identité, qui persiste,

de

l’habilitation, qui peut commencer et prendre fin.

---

Simulation 8 — Une personne, quatre fonctions différentes

Prenons un cas volontairement plus complexe, mais parfaitement réaliste au sein du GDSA43.

Pierre Martin est adhérent du GDSA43.

Mais il exerce également plusieurs fonctions :

• il est trésorier de l’association ;
• il est Technicien Sanitaire Apicole (TSA) ;
• il est référent frelon pour plusieurs communes ;
• il participe à une campagne de distribution de colis de médicaments vétérinaires dans le cadre du dispositif sanitaire.

Dans une architecture traditionnelle, cette situation pourrait conduire à multiplier les comptes, les rôles WordPress et les autorisations particulières.

Apisphère peut fonctionner autrement.

Une seule identité

Dans le Core Identité, Pierre reste une seule et même personne :

Identité Apisphère : #1274

Adhérent : actif
NAPI : renseigné
Email : vérifié
Téléphone : vérifié

Cloud Identity authentifie Pierre.

Identity Bridge établit ensuite la correspondance avec l’identité #1274.

Apisphère peut alors rechercher les habilitations actuellement attachées à cette personne.

Quatre habilitations différentes

Le moteur d’habilitation trouve :

Trésorier
Actif jusqu’au 31 décembre 2027

TSA
Habilitation active
Périmètre : visites qui lui sont affectées

Référent frelon
Actif pour les communes qui lui sont attribuées
Campagne : 2027

Distributeur de produits vétérinaires
Campagne sanitaire : 2027
Site de distribution : dépôt attribué
Période autorisée : du 3 au 17 avril 2027

Pierre n’a pourtant toujours qu’une seule identité.

Ce sont ses habilitations qui changent selon ce qu’il vient faire dans Apisphère.

---

8 h 30 — Pierre travaille comme trésorier

Pierre ouvre le Bureau.

Apisphère vérifie :

Identité : #1274
Habilitation demandée : trésorier
Statut : active

Le tableau de bord financier devient accessible.

Pierre peut, selon les droits définis :

• consulter les règlements ;
• effectuer les rapprochements ;
• suivre les cotisations ;
• contrôler certaines opérations comptables ;
• consulter les éléments nécessaires à sa fonction.

Mais son statut de trésorier ne lui donne aucun droit sanitaire supplémentaire.

Le principe reste :

une fonction = un périmètre d’accès.

---

10 h 15 — Pierre réalise une visite TSA

Pierre quitte l’espace Trésorerie et ouvre :

Mes visites TSA

Apisphère recalcule ses droits.

Cette fois, ce n’est plus son habilitation de trésorier qui est utilisée.

Le système recherche :

Habilitation TSA : active

puis :

Visite demandée : affectée à Pierre Martin

Accès autorisé.

Pierre peut renseigner la visite et les informations sanitaires nécessaires.

Mais être TSA ne lui permet pas pour autant de consulter l’ensemble des dossiers sanitaires du département.

Son accès reste limité à ce qui relève de sa mission.

---

14 h 00 — Un signalement de frelon arrive

Pierre reçoit ensuite un signalement concernant une commune dont il est référent.

Apisphère contrôle :

Identité #1274

puis :

Référent frelon : actif

et enfin :

Commune demandée : comprise dans le périmètre d’habilitation

Accès autorisé.

Pierre peut traiter ou valider le signalement selon les règles de la campagne.

Un signalement concernant une commune située hors de son secteur ?

Accès refusé : hors périmètre territorial.

Son statut de trésorier ou de TSA n’y change rien.

---

16 h 30 — Pierre distribue des colis de médicaments vétérinaires

Pierre rejoint ensuite un point de distribution du GDSA43.

Il ouvre le module :

Distribution sanitaire

Apisphère vérifie successivement :

Identité #1274 : authentifiée

Habilitation distributeur : active

Campagne 2027 : ouverte

Point de distribution : autorisé

Pierre peut alors prendre en charge la remise des colis qui lui sont affectés.

Par exemple :

Adhérent : Marie Durand

Commande sanitaire : CMD-2027-0482

Colis : préparé

Paiement : validé

Point de retrait : conforme

Pierre sélectionne :

Remettre le colis

Apisphère demande confirmation.

Colis remis à l’adhérent ?

Après validation :

Distribution enregistrée

Date : 12 avril 2027
Heure : 16 h 42
Distributeur : identité #1274
Commande : CMD-2027-0482
Statut : remise

L’opération est ainsi traçable.

Et surtout, Pierre n’a pas obtenu l’accès à cette fonction parce qu’il est trésorier, TSA ou référent frelon.

Il y accède parce qu’il possède, pour cette campagne et pendant cette période, une habilitation spéc

Cloud Identity ne doit pas devenir le fichier des adhérents

Ce point est essentiel.

Apisphère dispose progressivement de son propre Core Identité.

Il serait contre-productif de transférer toute la logique métier du GDSA43 dans Google.

Google Cloud Identity ne devrait pas décider qui est adhérent, qui possède tel NAPI ou quand une visite PSE doit être réalisée.

Ce sont des données métier propres au GDSA43.

L’architecture pourrait plutôt être représentée ainsi :

CLOUD IDENTITY
↓
authentifie la personne
↓
IDENTITY BRIDGE APISPHÈRE
↓
retrouve l’identité correspondante
↓
CORE IDENTITÉ
↓
Personne #1842
↓
MOTEUR D’HABILITATION
↓
adhérent / TSA / référent / vétérinaire / trésorier / secrétaire / président
↓
MODULES APISPHÈRE

Cette séparation est fondamentale.

---

Une identité, plusieurs métiers

On arrive alors à une architecture particulièrement intéressante pour une association.

Une personne n’a plus besoin d’avoir :

• un compte adhérent ;
• un compte TSA ;
• un compte frelon ;
• un compte WordPress ;
• éventuellement un compte Bureau.

Elle possède :

UNE identité

à laquelle sont rattachées :

PLUSIEURS habilitations.

On passe donc de :

un compte = un rôle

à :

une personne = une identité = plusieurs fonctions contrôlées.

C’est beaucoup plus proche de la réalité du GDSA43.

---

Et WordPress dans tout cela ?

WordPress resterait le moteur du portail.

Mais WordPress ne devrait progressivement plus être la source d’autorité pour les identités métier.

Il deviendrait plutôt un consommateur d’identité.

Lorsqu’une personne se connecte :

1. elle s’authentifie ;
2. son identité est vérifiée ;
3. Identity Bridge retrouve son identifiant Apisphère ;
4. le Core Identité fournit ses qualités métier ;
5. le moteur d’habilitation calcule ses droits ;
6. le module demandé décide enfin si l’action est autorisée.

On obtient ainsi quelque chose de beaucoup plus robuste qu’une collection de rôles WordPress.

---

Le piège à éviter : tout envoyer dans le cloud

Cloud Identity ne signifie pas que les données sanitaires doivent être transférées chez le fournisseur d’identité.

Au contraire.

Le fournisseur d’identité doit idéalement connaître le minimum nécessaire à l’authentification.

Les informations telles que :

• ruchers ;
• observations TSA ;
• traitements ;
• mortalités ;
• historique PSE ;
• données de piégeage ;
• commandes sanitaires ;

restent des données métier d’Apisphère.

Il faut appliquer un principe simple :

l’identité authentifie ; Apisphère autorise.

Cette séparation réduit les dépendances et facilite également une éventuelle évolution future vers un autre fournisseur d’identité.

---

Comment le mettre en œuvre dans Apisphère ?

Il serait imprudent de basculer brutalement tous les comptes.

La mise en œuvre peut être progressive.

Phase 1 — Consolider le Core Identité

Avant toute chose, chaque personne doit disposer d’un identifiant interne stable.

Par exemple :

APIS_PERSON_ID = 1842

Cet identifiant ne doit dépendre :

• ni de l’adresse électronique ;
• ni du NAPI ;
• ni du nom ;
• ni du compte WordPress.

Ces informations peuvent changer.

L’identité interne, elle, demeure.

---

Phase 2 — Formaliser les habilitations

Créer un véritable référentiel :

adherent
tsa
referent_frelon
coordinateur_frelon
veterinaire
administrateur
secretaire
tresorier
president

Mais également prévoir :

date de début
date de fin
périmètre territorial
campagne concernée
origine de l’habilitation
personne ayant validé l’habilitation

C’est beaucoup plus puissant qu’un simple rôle WordPress.

---

Phase 3 — Créer Identity Bridge

Identity Bridge devient la passerelle.

Il reçoit par exemple l’identité authentifiée :

cloud_subject = 109827364...

puis recherche :

APIS_PERSON_ID = 1842

Le système sait alors :

Cloud Identity affirme que cette personne est authentifiée.

et :

Apisphère sait que cette personne est Jean Dupont, adhérent #1842, TSA actif.

Les responsabilités restent clairement séparées.

---

Phase 4 — Commencer par le Bureau

Il serait inutile de migrer immédiatement plusieurs centaines d’adhérents.

Le meilleur laboratoire serait probablement le groupe le plus restreint et le plus sensible :

le Bureau.

Quelques comptes seulement permettraient de tester :

• SSO ;
• MFA ;
• association Cloud Identity ↔ Core Identité ;
• expiration des fonctions ;
• journalisation ;
• révocation ;
• récupération d’accès.

Google propose actuellement une édition Cloud Identity sans frais, avec 50 licences par défaut, ce qui rend techniquement possible un pilote limité sans équiper immédiatement l’ensemble des adhérents.

---

Phase 5 — Étendre aux profils sensibles

Après validation :

Bureau
↓
vétérinaire
↓
TSA
↓
référents territoriaux

Ce sont les profils pour lesquels l’identité et l’habilitation ont le plus de valeur.

---

Phase 6 — Ne traiter les adhérents qu’ensuite

Pour les adhérents ordinaires, la question mérite davantage de réflexion.

Créer plusieurs centaines d’identités Cloud simplement pour consulter un registre pourrait être disproportionné.

Il existe d’ailleurs chez Google plusieurs familles de technologies différentes selon qu’il s’agit de gérer le personnel d’une organisation ou les utilisateurs d’une application ; Cloud Identity et Identity Platform ne répondent pas exactement au même besoin.

Une architecture hybride peut donc être préférable :

Cloud Identity pour les acteurs internes et habilités

et

authentification Apisphère simplifiée pour les adhérents.

Identity Bridge masquerait cette différence aux modules métier.

---

À terme : un véritable poste de contrôle des accès

Dans le Bureau d’Apisphère pourrait apparaître une rubrique :

Identités et habilitations

Personnes actives : 327

Comptes authentifiés : 286

TSA actifs : 18

Référents frelon : 74

Membres du Bureau : 8

Comptes MFA conformes : 8/8

Habilitations arrivant à échéance : 3

Accès suspendus : 2

Anomalies : 1

Et en cliquant sur une personne :

Jean Dupont

Identité Apisphère : #1842

Email vérifié : ✓
Téléphone vérifié : ✓
Authentification externe : ✓
MFA : ✓

Fonctions

Adhérent — actif
TSA — actif jusqu’au 31/12/2028
Référent frelon — commune de Tence
Bureau — aucun droit

Derniers accès

21 octobre — registre sanitaire
20 octobre — visites TSA
18 octobre — documentation

On disposerait alors non plus seulement d’une base de comptes, mais d’une véritable gouvernance des identités.

---

Et demain ?

Cette architecture prend encore davantage de sens avec les développements futurs d’Apisphère.

Un Chromebook destiné à un TSA pourrait être associé à une identité.

Une tablette utilisée lors d’une distribution sanitaire pourrait être limitée aux fonctions nécessaires.

Un terminal en assemblée générale pourrait fonctionner en mode dédié.

Un agent logiciel chargé de surveiller Apisphère pourrait lui-même disposer d’une identité technique distincte d’un utilisateur humain.

Les technologies Google distinguent d’ailleurs les identités des utilisateurs humains des identités attribuées aux charges de travail et services informatiques.