Adhésions, boutique, sanitaire, frelon asiatique, tableaux de bord, applications mobiles, données de terrain… Le chantier numérique du GDSA43 entre dans une nouvelle phase. Après plusieurs mois consacrés à construire les différentes briques, le travail porte désormais autant sur leur fiabilité que sur leur mise à disposition progressive. Une évolution moins spectaculaire que l’apparition d’une nouvelle page Web, mais probablement beaucoup plus importante pour l’avenir de la plateforme.
Pendant longtemps, un site Internet associatif pouvait se résumer à quelques pages d’information, un formulaire de contact et éventuellement une boutique. Le développement de GDSA43.fr suit désormais une autre trajectoire.
L’objectif n’est plus seulement de publier de l’information, mais de disposer progressivement d’un véritable environnement numérique capable d’accompagner les activités du groupement : adhésions, sanitaire, commandes, lutte contre le frelon asiatique, cartographie, statistiques, communications, opérations de terrain et, demain, ruches connectées.
Cette évolution porte un nom : Apisphère.
Une architecture qui commence à prendre forme
Apisphère n’est pas une application unique. Il s’agit plutôt d’une architecture dans laquelle plusieurs modules spécialisés peuvent communiquer entre eux tout en conservant leurs responsabilités propres.
L’idée peut être résumée ainsi :
stabiliser → relier → cartographier → observer → alerter → décider → mobiliser.
Avant de produire des tableaux de bord sophistiqués ou des applications mobiles, il faut d’abord disposer de données fiables : savoir qui est adhérent, qui a renouvelé sa cotisation, combien de ruches sont déclarées, quelle commande appartient à qui ou encore quel référent intervient sur quelle commune.
Viennent ensuite les échanges entre les différents modules.
Ce principe évite progressivement de construire plusieurs systèmes parallèles contenant chacun leur propre copie des mêmes informations.
Première priorité : fiabiliser l’adhésion et la boutique
Le premier chantier devant réellement franchir la phase de mise en production concerne le parcours adhésion – cotisation – boutique.
Ce choix n’est pas anodin.
L’identité de l’adhérent constitue l’une des données centrales du système. Elle détermine ensuite l’accès à certains services, aux commandes sanitaires, à la carte d’adhérent ou encore à certaines informations personnelles.
Cette première « vague » fait actuellement l’objet d’une recette informatique particulièrement poussée.
Des parcours réels sont exécutés avec des comptes et paiements de test : création de compte, adhésion, panier, commande sanitaire, paiement Stripe en environnement de test, notifications et propagation des informations entre modules.
Mais ces commandes de recette doivent rester parfaitement séparées de l’activité réelle.
C’est pourquoi un important travail a également été consacré au confinement des données de test : elles doivent être observables pour permettre les contrôles, sans être comptabilisées comme de vraies commandes, de vraies adhésions ou de véritables opérations sanitaires.
Cette distinction peut sembler très technique. Elle est pourtant fondamentale.
Un « Gouverneur » avant d’ouvrir les services
Une autre évolution importante concerne la gouvernance technique de la plateforme.
Le passage en production ne doit plus dépendre uniquement d’un administrateur cliquant sur un bouton après quelques essais.
Apisphère s’appuie progressivement sur un mécanisme de contrôle capable d’indiquer si une fonction est réellement prête :
GO lorsque les conditions sont réunies ;
NO_GO lorsqu’un problème doit encore être corrigé.
Sécurité, identité, dépendances entre modules, paiements, formulaires, communications ou confinement des données pilotes peuvent ainsi empêcher automatiquement l’ouverture d’une vague.
Un NO_GO n’est donc pas un échec.
Il signifie au contraire que le contrôle joue son rôle : empêcher qu’une anomalie connue devienne un problème pour les utilisateurs.
Apisphère Bureau : un nouvel espace pour les responsables du GDSA43
Un nouveau chantier vient parallèlement d’être engagé : Apisphère Bureau.
Le constat de départ était simple.
Pour consulter une commande, une cotisation ou des statistiques, un président, un trésorier ou un responsable de campagne ne devrait pas obligatoirement devoir entrer dans l’administration technique de WordPress.
Le futur portail sera donc accessible directement depuis le navigateur, par exemple à l’adresse :
GDSA43.fr/bureau/
Après authentification, chaque membre du Bureau verra uniquement les informations correspondant à ses responsabilités.
Le trésorier pourra ainsi disposer d’une vision détaillée des cotisations, commandes et paiements.
Le président bénéficiera plutôt d’une synthèse générale de l’activité du GDSA43.
Le vice-président chargé du frelon asiatique pourra consulter les communes, les référents, les signalements, les captures et les indicateurs de campagne.
Même les vice-présidents ne disposant pas d’une délégation métier particulière pourront avoir accès à un tableau de bord général correspondant à leur fonction, sans pour autant accéder à des informations financières ou personnelles dont ils n’ont pas besoin.
Une même application sur Mac, Windows, tablette ou téléphone
Le choix d’une PWA — Progressive Web App — répond également à une réalité très concrète du monde associatif : les bénévoles n’utilisent pas tous le même matériel.
Certains travaillent sous Windows et Chrome, d’autres disposent d’un iMac, d’un iPad ou d’un smartphone Android.
Développer et maintenir plusieurs applications spécifiques aurait peu de sens.
Avec une PWA, le même portail Web peut être utilisé sur tous ces appareils et même être installé sous forme d’icône, avec une présentation proche d’une application classique.
Le système reste cependant centralisé sur GDSA43.fr.
Consulter, filtrer… et récupérer les données
Apisphère Bureau ne doit pas devenir seulement un tableau de bord agréable à regarder.
Les responsables doivent pouvoir réellement travailler avec les informations auxquelles ils ont accès.
Des fonctions d’export sont donc prévues :
CSV, pour disposer d’un format universel ;
XLSX, pour travailler directement avec Excel, Numbers ou des logiciels compatibles.
Un trésorier pourra par exemple filtrer une période ou une catégorie de commandes, puis récupérer le résultat dans un tableur.
Mais une possibilité plus intéressante encore est en préparation.
Une prise numérique pour Excel, Access et d’autres logiciels
Le GDSA43 disposait déjà d’un module expérimental, GDSA43 Bureau API, initialement conçu pour alimenter une application installée sur les ordinateurs des membres du Bureau.
Cette expérimentation n’est pas abandonnée.
Au contraire, elle devient l’une des briques d’Apisphère Bureau.
L’interface destinée aux humains sera la PWA.
L’API constituera, elle, la prise numérique destinée aux machines.
Schématiquement :
GDSA43
│
BUREAU API
│
┌─────────────┼─────────────┐
│ │ │
▼ ▼ ▼
/bureau/ Excel applications
PWA / tableur externes
Un classeur Excel pourrait ainsi, à terme, interroger directement les informations autorisées et les actualiser sans qu’il soit nécessaire d’exporter manuellement un fichier à chaque fois.
Le même principe pourrait servir à une base Access, un outil d’analyse, un logiciel décisionnel ou une future application métier.
Il ne s’agit surtout pas d’ouvrir directement la base de données du site sur Internet.
Toutes les demandes passent par une API sécurisée, avec authentification, droits limités et possibilité de révoquer un accès.
Une seule donnée, plusieurs façons de la consulter
Cette évolution illustre assez bien la philosophie générale d’Apisphère.
Une commande WooCommerce ne devrait pas être copiée dans cinq systèmes différents pour être affichée à cinq endroits.
Elle reste une commande WooCommerce.
Apisphère Bureau, un export CSV, Excel ou une application externe demandent simplement au système de leur transmettre la représentation à laquelle ils ont droit.
On tend ainsi vers un principe particulièrement important :
une seule source de vérité, plusieurs usages.
C’est également ce qui doit permettre de conserver une plateforme maintenable malgré la multiplication progressive des services.
Lecture seule d’abord
Pour cette première version d’Apisphère Bureau, la prudence reste de mise.
Le portail est conçu principalement en lecture seule.
Les responsables pourront consulter, rechercher, filtrer et exporter, mais pas modifier directement les données métier depuis le nouveau portail.
Le trésorier pourra donc, par exemple, identifier une commande depuis son tableau de bord puis utiliser l’administration habituelle lorsqu’une intervention exceptionnelle est réellement nécessaire.
Des opérations métier pourront éventuellement être ajoutées plus tard.
Mais elles seront introduites une par une, avec leurs propres contrôles et leur propre recette.
Le but n’est pas de reproduire toute l’administration WordPress sur une nouvelle page.
Les prochaines briques
Le portail Bureau ne représente qu’une étape supplémentaire.
L’architecture développée doit progressivement pouvoir accueillir d’autres activités : distribution des commandes sanitaires, campagnes frelon, assemblées générales, registre sanitaire, cartographie, observatoire départemental et, à plus long terme, Apisphère BeeNode, le projet de réseau de ruches connectées.
Ces développements ne seront cependant pas tous ouverts simultanément.
La logique retenue est désormais celle des vagues successives.
Une fonction est développée.
Elle est diagnostiquée.
Elle entre en recette.
Elle passe éventuellement par un pilote limité.
Puis seulement, lorsque tous les indicateurs nécessaires sont au vert, elle peut rejoindre la production.
Un chantier collectif… même lorsqu’il est invisible
Une grande partie de ce travail reste naturellement invisible pour l’adhérent.
Lorsqu’une page fonctionne correctement, personne ne voit les contrôles d’accès, les API, les journaux techniques, les tests automatisés ou les mécanismes empêchant une commande fictive d’être comptabilisée dans les statistiques.
Et c’est précisément le but.
Un outil numérique associatif doit finir par paraître simple.
Mais cette simplicité pour l’utilisateur suppose en arrière-plan beaucoup de rigueur.
Le chantier actuel de GDSA43.fr entre ainsi dans une phase différente : il s’agit moins d’ajouter rapidement de nouvelles fonctions que de transformer progressivement une accumulation d’outils en un système cohérent, gouverné et durable.
La mise en production n’est donc pas une ligne d’arrivée.
Elle marque plutôt le moment où les outils commencent réellement à pouvoir être confiés à leurs utilisateurs.
Et, pour le GDSA43, cette étape se rapproche.
