Identités, adhésions, PSE, visites sanitaires, frelon asiatique, cartographie, paiements, applications mobiles… Après des mois de conception, Apisphère entre dans sa dernière ligne droite. Objectif : une première mise en production opérationnelle au 1er janvier 2027.
Il arrive un moment dans tout projet où les idées doivent céder la place à l’épreuve du réel.
Pour Apisphère, ce moment approche.
Depuis plusieurs mois, nous travaillons à la construction d’un système numérique destiné à réunir dans un même environnement une grande partie des activités d’une organisation sanitaire apicole : adhérents, cotisations, Programme sanitaire d’élevage (PSE), visites des techniciens sanitaires apicoles (TSA), commandes, paiements, lutte contre le frelon asiatique, référents communaux, cartographie, campagnes de piégeage et, progressivement, observation sanitaire.
Le GDSA43 doit constituer le premier terrain d’exploitation grandeur nature du système.
À la date du 12 octobre 2026, il reste exactement 81 jours avant le 1er janvier 2027.
Le compte à rebours est donc lancé.
Mais mettre Apisphère en production ne signifie pas terminer tout ce que nous avons imaginé.
Cela signifie quelque chose de beaucoup plus important :
rendre fiables les fonctions dont nous avons réellement besoin.
Apisphère, ce n’est pas simplement un nouveau site Internet
Il faut commencer par dissiper un malentendu.
Apisphère n’est pas destiné à être une nouvelle présentation du site du GDSA43.
Il s’agit progressivement de construire un véritable ERP associatif et sanitaire apicole.
ERP signifie Enterprise Resource Planning, que l’on traduit généralement par progiciel de gestion intégré.
Le terme semble particulièrement industriel pour parler d’abeilles.
Pourtant, le principe est simple : éviter que chaque activité fonctionne dans son propre petit univers informatique.
Aujourd’hui, une organisation apicole peut rapidement accumuler :
- un fichier des adhérents ;
- un autre fichier pour les visites sanitaires ;
- des listes de TSA ;
- des commandes ;
- une boutique ;
- des paiements ;
- des courriels ;
- des listes de référents ;
- des communes ;
- des déclarations de frelons ;
- des tableaux de piégeage ;
- des documents réglementaires ;
- des historiques de cotisations.
Et, bien entendu, chacun de ces fichiers finit par avoir sa propre vérité.
C’est précisément ce qu’Apisphère cherche à éviter.
Une personne, une identité
L’une des décisions structurantes du projet paraît presque évidente :
une personne ne doit exister qu’une seule fois dans le système.
Elle peut ensuite être adhérente, apicultrice, TSA, référente frelon, membre du Bureau ou cumuler plusieurs fonctions.
Mais cela ne doit pas conduire à créer cinq personnes différentes dans cinq bases de données.
Apisphère distingue donc trois notions.
L’identité représente la personne.
Le compte lui permet éventuellement de s’authentifier.
Les rôles et habilitations déterminent ce qu’elle est autorisée à faire.
Cette distinction est fondamentale.
Un adhérent n’a pas nécessairement besoin d’un compte informatique pour exister dans Apisphère.
Un piégeur de frelon asiatique non plus.
En revanche, un responsable devant administrer certaines données pourra disposer des droits nécessaires.
Cette architecture doit également permettre de mieux maîtriser les doublons, les changements d’adresse électronique ou de téléphone et les différents identifiants professionnels.
Le NAPI, numéro d’apiculteur, constitue ainsi une information métier importante, mais il ne doit jamais devenir la clé technique permettant au système de reconnaître définitivement une personne.
Un NAPI peut être absent, modifié ou remplacé.
L’identité interne d’Apisphère, elle, doit rester stable.
Octobre : figer les fondations
La première échéance est proche.
Du 12 au 25 octobre : audit général
Avant d’ajouter de nouvelles fonctions, il faut désormais examiner ce qui existe.
Le travail porte notamment sur :
- l’inventaire des modules ;
- leurs versions ;
- leurs dépendances ;
- les échanges entre composants ;
- la cohérence de la base de données ;
- les doublons éventuels ;
- les sauvegardes ;
- les habilitations ;
- les anomalies déjà détectées.
Le principe devient désormais :
on ne construit plus une nouvelle aile de la maison avant d’avoir vérifié les fondations.
Le 25 octobre, l’architecture fonctionnelle de la version 1.0 devra être figée.
Cela ne signifie pas qu’Apisphère cessera d’évoluer.
Au contraire.
Mais toute fonction non indispensable au démarrage pourra être repoussée après le 1er janvier.
Novembre : les adhérents au cœur du système
La deuxième grande étape concerne les identités, les adhésions et les cotisations.
Nous disposons notamment d’un premier ensemble d’environ soixante adhérents provenant du suivi des visites TSA, pour une population totale d’environ trois cents adhérents à intégrer progressivement.
Cette migration est beaucoup plus délicate qu’un simple copier-coller.
Pour chaque personne, il faut pouvoir vérifier :
- nom et prénom ;
- coordonnées ;
- commune ;
- NAPI lorsqu’il est connu ;
- historique d’adhésion ;
- cheptel déclaré ;
- informations sanitaires utiles ;
- éventuelle visite PSE ;
- rôles particuliers.
Et surtout, il faut détecter les doublons.
Deux fiches ressemblantes ne doivent jamais être fusionnées automatiquement simplement parce que deux personnes portent le même nom.
La machine peut signaler un doute. La décision finale doit rester humaine.
15 novembre : tester toute la chaîne d’adhésion
À cette date, nous voulons pouvoir simuler un parcours complet :
identité → adhésion → cotisation → paiement → confirmation → activation.
Chaque étape devra être traçable.
Un paiement ne devra jamais être considéré comme effectué simplement parce qu’un utilisateur revient sur une page indiquant « paiement réussi ».
Apisphère devra recevoir et vérifier la confirmation provenant réellement du système de paiement.
Ce point peut sembler technique.
Il ne l’est pas.
Dès lors qu’un système gère de l’argent, une règle doit prévaloir :
on ne suppose jamais qu’un paiement a eu lieu ; on le vérifie.
Fin novembre : faire entrer le sanitaire dans Apisphère
Le Programme sanitaire d’élevage constitue naturellement l’un des grands chantiers.
Le système doit progressivement permettre de suivre :
- les adhérents engagés dans le PSE ;
- les visites sanitaires ;
- les TSA ;
- les échéances ;
- les ruchers et cheptels ;
- les interventions ;
- les historiques utiles.
Pour le GDSA43, chaque adhérent est engagé dans le PSE.
La visite sanitaire quinquennale doit donc pouvoir devenir une véritable échéance suivie par le système.
L’objectif n’est évidemment pas de remplacer le vétérinaire, le TSA ou le responsable sanitaire par un logiciel.
C’est exactement l’inverse.
Le logiciel doit leur éviter de perdre du temps à rechercher l’information dont ils ont besoin.
Décembre : le frelon asiatique entre dans la ruche numérique
Le troisième grand chantier opérationnel concerne le frelon asiatique.
Là encore, la difficulté n’est pas seulement informatique.
Il faut traduire une organisation humaine et territoriale dans le système.
Une commune peut disposer de plusieurs référents.
Un référent peut intervenir dans plusieurs communes.
Des dizaines de piégeurs peuvent participer à une campagne sans qu’il soit souhaitable de leur créer autant de comptes administratifs.
Apisphère doit donc gérer plusieurs niveaux :
Piégeur → Référent → Responsable frelon → Bureau.
Le piégeur pourra utiliser une petite application web installable sur smartphone — une PWA — pour renseigner ses captures.
Chaque piège pourra être associé à un numéro permanent et, si le dispositif est retenu, à un QR code.
Les informations pourront comprendre :
- localisation ;
- date de pose ;
- type de piège ;
- appât utilisé ;
- captures de fondatrices ;
- captures accidentelles ;
- photographie éventuelle ;
- date de retrait.
Le référent communal pourra ensuite contrôler les informations relevant de son secteur.
Et si Internet ne passe pas au fond du vallon ?
C’est une question particulièrement concrète en milieu rural.
Une application destinée au terrain ne peut pas partir du principe que chaque rucher ou chaque emplacement de piège dispose d’une excellente connexion.
La PWA doit donc être capable de fonctionner, autant que possible, hors connexion.
Le piégeur renseigne son observation.
Le téléphone la conserve.
Lorsque la connexion redevient disponible, les informations sont synchronisées.
C’est beaucoup moins spectaculaire qu’une démonstration d’intelligence artificielle.
Mais sur le terrain, c’est probablement beaucoup plus utile.
12 décembre : première répétition générale
À cette date, le dispositif Frelon devra pouvoir fonctionner en simulation.
Pas nécessairement avec trois cents utilisateurs.
Mais suffisamment pour tester toute la chaîne :
piège → QR code → piégeur → saisie → synchronisation → référent → validation → cartographie → statistiques.
Une anomalie découverte le 12 décembre est encore une anomalie que l’on peut corriger.
Une anomalie découverte en pleine campagne de piégeage est déjà une mauvaise surprise.
20 décembre : le jour du GO / NO-GO
C’est probablement la date la plus importante du calendrier.
Le 20 décembre, il faudra répondre à une question simple :
Apisphère est-il suffisamment fiable pour entrer en production ?
Et la bonne réponse ne sera pas obligatoirement « oui ».
Une mise en production sérieuse doit permettre un NO-GO.
Si une fonction essentielle présente encore un risque important, elle doit être corrigée ou provisoirement désactivée.
Durant cette phase, nous testerons notamment :
- la création d’un nouvel adhérent ;
- la réactivation d’un ancien adhérent ;
- une cotisation 2027 ;
- un paiement ;
- une commande ;
- une visite TSA ;
- l’attribution d’un rôle ;
- une déclaration de piégeage ;
- les notifications ;
- les sauvegardes ;
- et surtout la restauration des données.
Car une sauvegarde que personne n’a jamais essayé de restaurer reste essentiellement une promesse.
Du 21 au 31 décembre : on ne touche presque plus à rien !
Cette période doit constituer une phase de gel.
Plus question d’ajouter soudainement « la petite fonctionnalité géniale qui ne prendra que dix minutes ».
Les informaticiens savent généralement ce que signifie cette phrase.
Elle peut occuper trois jours et casser deux choses qui fonctionnaient parfaitement auparavant.
Durant les derniers jours de décembre, seuls les problèmes importants devront être corrigés.
Il faudra également :
- vérifier les données ;
- contrôler les droits ;
- effectuer les sauvegardes ;
- préparer les procédures de retour arrière ;
- finaliser la documentation ;
- numéroter les versions ;
- préparer l’accompagnement des utilisateurs.
Le 31 décembre 2026, nous devons disposer d’une version candidate à la production.
1er janvier 2027 : Apisphère V1.0
Si les tests sont concluants, le 1er janvier 2027 marquera donc la première véritable mise en production d’Apisphère.
Mais il faut être précis sur ce que signifie cette date.
Apisphère ne sera pas « terminé ».
Un système informatique vivant n’est d’ailleurs jamais réellement terminé.
La V1.0 devra surtout assurer correctement les fonctions essentielles :
| Domaine | Situation attendue au 1er janvier |
|---|---|
| Identités | Opérationnel |
| Adhérents | Opérationnel |
| Cotisations 2027 | Opérationnel |
| Paiements | Opérationnel |
| Boutique | Opérationnel |
| PSE | Opérationnel |
| Visites TSA | Opérationnel |
| Notifications | Opérationnel |
| Référents communaux | Opérationnel |
| Frelon asiatique | Prêt pour la campagne |
| PWA Piégeurs | Testée et validée |
| Cartographie | Fonctions essentielles |
| Surveillance technique | Active |
Tout ne sera volontairement pas terminé
C’est probablement l’une des décisions les plus importantes du projet.
Nous avons beaucoup d’idées pour Apisphère.
Parmi elles figurent notamment les ruchers connectés BeeNode, des fonctions avancées d’observation sanitaire, la gestion de terminaux de terrain, des tableaux de bord plus élaborés et, à terme, une mutualisation possible de certains outils entre plusieurs structures apicoles.
Nous travaillons également sur l’utilisation raisonnée d’agents d’intelligence artificielle pour surveiller le fonctionnement du système, détecter des anomalies et aider à préparer des diagnostics ou des correctifs.
Mais aucune de ces fonctions ne doit compromettre la fiabilité de la première version.
Une V1.0 qui fait dix choses correctement est préférable à une V1.0 qui prétend en faire cinquante et en casse quinze.
Janvier 2027 : le véritable test commence
Le passage en production ne sera donc pas l’arrivée.
Ce sera le départ.
Pendant les premières semaines de janvier, Apisphère devra faire l’objet d’une surveillance renforcée.
Nous examinerons notamment :
- les erreurs rencontrées ;
- les parcours incompris ;
- les données incohérentes ;
- les performances ;
- les notifications ;
- les paiements ;
- les demandes des utilisateurs.
Les premiers utilisateurs deviendront ainsi, d’une certaine manière, les derniers testeurs du système.
Mais avec une différence essentielle : leurs difficultés ne devront plus seulement être corrigées.
Elles devront nous apprendre quelque chose.
Février : préparer la campagne Frelon
Une fois les fonctions associatives stabilisées, février sera principalement consacré à la préparation opérationnelle de la campagne contre le frelon asiatique.
Les communes, référents, pièges et accès devront être vérifiés.
Les QR codes pourront être distribués.
Les piégeurs devront disposer d’instructions suffisamment simples pour qu’une formation informatique ne soit pas nécessaire.1
C’est un critère auquel nous tenons particulièrement.
Si une personne doit lire vingt pages de documentation avant de déclarer trois frelons capturés dans un piège, nous aurons raté quelque chose.
Mars : Apisphère sort sur le terrain
Avec le démarrage de la campagne de piégeage des fondatrices, Apisphère devra quitter définitivement le confort du bureau.
Smartphones, campagnes, référents, communes, pièges et cartographie vont alors se confronter au terrain.
Et c’est probablement à ce moment-là que nous saurons réellement si notre architecture était la bonne : non parce qu’elle ne rencontrera jamais d’incident, mais parce qu’elle devra empêcher qu’un petit incident devienne un gros problème.2
De WordPress à un système apicole territorial
Apisphère fonctionne aujourd’hui dans l’écosystème WordPress.3
Mais notre objectif n’est pas d’empiler des extensions.
Nous essayons au contraire de construire des composants spécialisés capables de communiquer entre eux selon des règles précises.
Identité, sanitaire, communes, référents, cartographie, signalements ou campagnes doivent rester des domaines distincts.
Cette architecture présente un intérêt majeur pour l’avenir.
Un module peut évoluer sans imposer la reconstruction de tout le système.
Et surtout, certaines briques pourraient un jour devenir mutualisables.4
Une question dépasse désormais le GDSA43
C’est peut-être finalement l’aspect le plus intéressant de cette aventure.
Beaucoup d’organisations apicoles sont confrontées aux mêmes difficultés :
Comment gérer plusieurs centaines d’adhérents ?
Comment conserver l’historique sanitaire ?
Comment suivre les visites ?
Comment coordonner plusieurs centaines de bénévoles ?
Comment gérer une campagne territoriale contre le frelon asiatique ?
Comment produire des données utiles sans transformer les apiculteurs en agents administratifs ?
Comment protéger les données personnelles ?
Et comment faire tout cela avec les moyens limités d’une association ?
Apisphère constitue notre réponse expérimentale à ces questions.
Elle sera certainement imparfaite.
Elle évoluera.
Certaines idées seront abandonnées.
D’autres apparaîtront grâce aux utilisateurs.
C’est précisément ainsi qu’un outil devient utile.
81 jours
Au moment où nous écrivons ces lignes, il reste donc 81 jours.
Le calendrier est serré :
25 octobre : architecture V1.0 figée.
15 novembre : identités, adhésions et cotisations en recette.
30 novembre : boutique et PSE opérationnels.
12 décembre : module Frelon et PWA testés.
20 décembre : décision GO / NO-GO.
31 décembre : version candidate.
1er janvier 2027 : mise en production d’Apisphère V1.0.
Puis viendra le printemps.
Et avec lui les abeilles, les visites de ruchers, les fondatrices de frelons, les piégeurs, les TSA, les adhérents et toutes ces situations que nous n’aurons probablement pas imaginées derrière nos écrans.
C’est alors qu’Apisphère devra démontrer son utilité.
Car au fond, le véritable objectif du projet n’est pas de numériser l’apiculture.
Il est exactement inverse :
utiliser intelligemment le numérique pour laisser davantage de temps aux humains pour s’occuper des abeilles.
- L’objectif n’est pas de supprimer toute explication, mais d’éviter qu’utiliser Apisphère nécessite une véritable formation informatique. Un piégeur doit pouvoir comprendre les opérations essentielles en quelques minutes : scanner le QR code de son piège, ouvrir la PWA, enregistrer un relevé, indiquer le nombre de frelons capturés, éventuellement prendre une photographie puis valider l’observation.
L’accompagnement pourrait notamment reposer sur une série de micro-vidéos de démonstration de 30 secondes à 2 minutes, accessibles directement depuis l’application par un bouton « ? » ou « Comment faire ? ».
Plutôt qu’un long tutoriel, chaque vidéo répondrait à une seule question : « Comment installer la PWA sur mon téléphone ? », « Comment scanner le QR code de mon piège ? », « Comment déclarer mes captures ? », « Que faire si je n’ai pas de réseau ? », « Comment corriger une erreur ? » ou encore « Comment ajouter une photo ? ».
L’IA générative peut faciliter considérablement la production et surtout la maintenance de ces supports : génération d’une voix off, sous-titrage automatique, animation d’un personnage ou d’un curseur, traduction éventuelle, création de variantes très courtes et mise à jour d’une séquence lorsqu’une interface évolue. Les captures ou simulations utilisées devront naturellement correspondre à la version réellement déployée d’Apisphère : une vidéo parfaitement réalisée montrant un ancien écran serait plus déroutante qu’utile.
Chaque tutoriel devrait donc porter un numéro de version et une date, comme la documentation générale d’Apisphère.
On peut même envisager une aide contextuelle : depuis l’écran « Relevé du piège », le bouton d’assistance ouvre directement la vidéo consacrée à la saisie d’un relevé, et non une bibliothèque de vingt tutoriels dans laquelle l’utilisateur doit rechercher son problème.
Ces vidéos ne remplaceraient pas complètement une fiche pratique imprimable — utile sur le terrain et pour les personnes moins à l’aise avec le numérique — ni l’aide d’un référent communal. Elles constitueraient un niveau d’assistance supplémentaire, disponible en permanence.
Le meilleur indicateur restera cependant extrêmement simple : si nous devons produire une vidéo de dix minutes pour expliquer comment déclarer trois frelons dans un piège, le problème ne vient probablement pas du piégeur… mais de l’interface. ↩︎ - « Savoir si notre architecture était la bonne » ne signifie pas qu’Apisphère devrait fonctionner sans jamais rencontrer d’erreur. Une architecture robuste se juge aussi à sa capacité à détecter une anomalie, à empêcher qu’elle se propage, à conserver la trace de ce qui s’est produit et à permettre un retour à un état fiable.
Avant la mise en service, plusieurs incidents devront donc être volontairement simulés. Par exemple : un piégeur saisit deux fois le même relevé ; un téléphone perd sa connexion pendant l’enregistrement d’une capture ; deux référents corrigent simultanément la même donnée ; un QR code renvoie vers un piège désactivé ; une personne existe deux fois dans la base ; un paiement est confirmé deux fois ; une notification ne part pas ; une mise à jour provoque une erreur ; ou une mauvaise règle métier a simplement été imaginée lors de la conception.
Apisphère devra alors appliquer plusieurs niveaux de protection : détecter → isoler → journaliser → alerter → corriger → vérifier, avec restauration ou retour arrière lorsque cela est nécessaire.
Prenons un exemple. Un piégeur enregistre trois fondatrices alors qu’il n’a plus de réseau. La PWA conserve l’information localement. Il appuie une seconde fois sur « Enregistrer », puis le téléphone retrouve Internet. Deux transmissions identiques arrivent au serveur. Le système ne devrait pas comptabiliser six frelons : un identifiant unique de l’opération permet de reconnaître la répétition, la seconde transmission est neutralisée et l’événement reste journalisé.
Autre situation, plus délicate : le logiciel fonctionne exactement comme prévu, mais nous nous sommes trompés dans la règle métier. Nous découvrons par exemple sur le terrain que la validation systématique de chaque relevé par un référent ralentit inutilement la campagne. Ce n’est ni un bug ni une panne : c’est une faute d’appréciation dans la conception. La règle doit alors pouvoir être modifiée sans reconstruire tout le module, par exemple en réservant la validation humaine aux relevés incohérents ou signalés comme atypiques.
C’est précisément l’intérêt d’une architecture modulaire : distinguer l’incident technique, l’erreur de donnée, l’erreur humaine et la mauvaise règle métier, car leurs réponses ne sont pas les mêmes.
Enfin, les composants sensibles — identités, habilitations, paiements, données sanitaires — ne doivent pas être corrigés automatiquement en production par une intelligence artificielle. La surveillance peut détecter et diagnostiquer l’anomalie ; un correctif peut être préparé et testé en environnement de staging ; mais les opérations présentant un risque important doivent rester soumises à validation humaine.
Le véritable test d’Apisphère ne sera donc pas l’absence totale d’incidents, objectif irréaliste, mais sa capacité à faire en sorte qu’un petit incident reste un petit incident. ↩︎ - Dire qu’« Apisphère fonctionne aujourd’hui dans l’écosystème WordPress » signifie que WordPress constitue actuellement son environnement d’exécution et lui fournit une partie de ses fondations techniques : gestion du site, utilisateurs, administration, base de données, API REST, extensions et mécanismes de sécurité ou de mise à jour. WooCommerce apporte notamment certaines fonctions commerciales utilisées pour les commandes et la boutique.
Mais Apisphère ne consiste pas à empiler des extensions WordPress indépendantes.
Ses fonctions métier sont progressivement organisées en composants spécialisés — identité, adhérents, sanitaire, communes, référents, cartographie, frelon asiatique, campagnes, etc. — auxquels s’ajoutent des services communs comme le Bus interne, le Kernel ou le SDK Apisphère.
L’objectif est d’éviter qu’un module aille directement modifier les données d’un autre module sans contrôle. Les échanges doivent autant que possible passer par des interfaces et des règles définies. Ainsi, le module Frelon peut avoir besoin de savoir qu’une personne est référente d’une commune sans devenir lui-même responsable de son identité.
Cette séparation présente également un intérêt pour l’avenir. WordPress est aujourd’hui le socle d’Apisphère, mais il ne doit pas devenir une prison architecturale. Si, dans quelques années, une fonction nécessite un service extérieur, une application mobile, un moteur cartographique spécialisé ou une infrastructure différente, elle devrait pouvoir communiquer avec Apisphère par ses interfaces plutôt que nécessiter la reconstruction de l’ensemble du système.
Prenons un exemple : la PWA utilisée par les piégeurs peut fonctionner sur un smartphone sans leur donner accès à l’administration WordPress. Elle dialogue avec les services dont elle a besoin et ne voit que les informations auxquelles elle est autorisée à accéder.
Même principe pour un futur rucher connecté BeeNode : un capteur installé sous une ruche n’a évidemment aucune raison de « se connecter à WordPress ». Il transmettrait ses mesures à une interface prévue à cet effet ; Apisphère pourrait ensuite les exploiter, les historiser ou déclencher une alerte.
WordPress constitue donc le terrain sur lequel Apisphère est construit aujourd’hui ; l’architecture modulaire vise à faire en sorte que les murs porteurs appartiennent progressivement à Apisphère lui-même. ↩︎ - Par « briques mutualisables », nous entendons des modules d’Apisphère qui pourraient, à terme, être utilisés par plusieurs GDSA ou organisations apicoles sans que chacun ait à développer son propre outil et sans nécessairement partager leurs données. Chaque structure conserverait son identité, ses adhérents, ses habilitations et ses données, tandis que certains composants techniques seraient communs.
Par exemple, un même module Frelon asiatique pourrait permettre à plusieurs GDSA de gérer leurs campagnes de piégeage, leurs référents communaux, leurs pièges et leur cartographie selon un socle commun. De même, une brique PSE / visites TSA pourrait fournir les mêmes outils de planification, de suivi et de traçabilité à plusieurs structures, chacune restant responsable de son propre programme sanitaire et de ses données.
La mutualisation porterait ainsi d’abord sur le logiciel, sa maintenance et ses évolutions, et non sur la fusion des fichiers des différentes associations. ↩︎
