Catégorie : Recherche & innovation

Avant d’ouvrir largement les nouveaux services du GDSA43, chaque fonction doit franchir une phase de recette : tests réels, contrôles de sécurité, vérification des données, paiements en mode test et validation des dépendances entre modules. Une étape peu visible, parfois presque administrative, mais essentielle pour transformer un site en une plateforme fiable, traçable et prête à être mise en production.

La mise en production par vagues, une étape discrète mais décisive

Le développement d’un site comme celui du GDSA43 ne consiste pas seulement à créer des pages, installer des extensions ou ajouter de nouvelles fonctions. À partir du moment où la plateforme gère des adhésions, des paiements, des commandes de produits sanitaires, des données personnelles ou des communications automatisées, une autre question devient essentielle : comment être certain que tout fonctionne correctement avant de l’ouvrir réellement aux utilisateurs ?

C’est précisément le rôle de ce que nous appelons, dans le développement d’Apisphère et du GDSA43, la « vague recette ».

Le terme peut paraître administratif. Il l’est un peu. Mais cette procédure constitue surtout une forme de contrôle qualité avant mise en service.

Une « recette », qu’est-ce que cela signifie ?

Dans le vocabulaire informatique, la recette est la période pendant laquelle une application est testée dans des conditions aussi proches que possible de son fonctionnement réel.

Le logiciel existe. Les fonctions sont installées. Les pages peuvent être accessibles. Mais cela ne signifie pas encore que le service est ouvert au public.

La recette consiste à répondre méthodiquement à plusieurs questions :

• le parcours fonctionne-t-il du début à la fin ?
• les bonnes personnes disposent-elles des bons droits ?
• les données sont-elles enregistrées au bon endroit ?
• un paiement entraîne-t-il les bonnes conséquences ?
• les courriels partent-ils seulement lorsqu’ils doivent partir ?
• une commande sanitaire est-elle correctement identifiée ?
• les données de test restent-elles séparées des données réelles ?
• une anomalie peut-elle être détectée avant d’avoir des conséquences ?

Tant que ces contrôles ne sont pas satisfaisants, la fonction reste en pilote.

Pourquoi parler de « vagues » ?

Le GDSA43 devient progressivement une plateforme composée de nombreux services : adhésion, boutique, sanitaire, distributions, lutte contre le frelon asiatique, registre sanitaire, cartographie, observatoire, applications mobiles ou encore ruches connectées.

Les ouvrir tous simultanément serait une mauvaise méthode.

Une anomalie dans une fonction pourrait se propager à plusieurs autres modules et il deviendrait beaucoup plus difficile d’identifier son origine.

Le principe retenu est donc celui d’une mise en production progressive.

Schématiquement :

développement → diagnostic → recette → pilote → validation → production

Chaque grande fonction constitue une vague indépendante.

La première concerne par exemple un élément particulièrement sensible : l’adhésion et la boutique.

La Vague 1 : adhérer, être reconnu, commander

Cette première vague permet notamment de vérifier tout le parcours :

visiteur → adhésion → création ou reconnaissance de l’identité → paiement → statut d’adhérent → accès à la boutique → commande

Sur le papier, cela paraît relativement simple.

En réalité, plusieurs systèmes interviennent simultanément : WordPress, WooCommerce, Stripe, le système d’identité GDSA43, les règles d’adhésion, le contrôle d’accès à la boutique, les commandes sanitaires, les notifications et certains échanges avec Brevo.

La recette consiste donc à suivre un utilisateur comme s’il était réellement adhérent.

Un compte de test peut :

• entrer sur la plateforme ;
• adhérer ;
• effectuer un paiement avec le système Stripe en mode test ;
• se connecter ;
• accéder à la boutique ;
• commander un produit sanitaire ;
• choisir un lieu de mise à disposition ;
• recevoir les droits correspondant à sa situation.

À chaque étape, le système est observé.

Tester sans polluer les vraies données

C’est l’un des aspects les plus importants de cette procédure.

Un test réalisé sur le vrai site ne doit pas devenir par accident :

• une vraie adhésion ;
• une vraie recette comptable ;
• une commande à préparer ;
• une délivrance sanitaire ;
• une statistique officielle ;
• une inscription réelle dans une campagne ;
• un message envoyé aux responsables ;
• ou une synchronisation définitive vers un service extérieur.

Les commandes de recette doivent donc porter des marqueurs de confinement.

Autrement dit, le système sait :

« Cette commande existe réellement dans WooCommerce, mais elle appartient à une campagne de test. »

Les modules qui utilisent les commandes doivent ensuite respecter cette information.

Le contrôle actuellement mis en place vérifie ainsi que les différents consommateurs — statistiques, sanitaire, distributions, courriels, factures, Bus interne, adhésions ou communications — reconnaissent correctement ce contexte de test.

C’est une précaution assez invisible pour l’utilisateur, mais fondamentale pour la fiabilité future de la plateforme.

Le rôle du « Gouverneur »

Pour éviter que chaque extension décide seule si une fonction est prête, la plateforme dispose désormais d’un dispositif central de contrôle que nous appelons le Gouverneur.

Il agit un peu comme un responsable de mise en service.

Il ne se contente pas de demander :

« Est-ce que la page fonctionne ? »

Il vérifie plusieurs familles de conditions : sécurité, identité, adhésion, boutique, paiement, communications, intégrité des données et dépendances entre modules.

Il peut alors délivrer deux conclusions simples :

GO : les conditions requises sont réunies.

NO_GO : au moins une condition bloquante reste à corriger.

Une vague peut donc être techniquement installée et parfaitement visible tout en restant volontairement en NO_GO.

Ce n’est pas un échec.

C’est précisément le rôle du dispositif.

Le NO_GO est parfois une bonne nouvelle

Lors des essais de la première vague, plusieurs contrôles ont effectivement arrêté la procédure.

Un diagnostic de sécurité a par exemple détecté une archive de sauvegarde placée dans la racine publique du serveur.

Le site fonctionnait parfaitement.

Pourtant, le Gouverneur a refusé de considérer la plateforme comme prête.

La sauvegarde a été retirée de l’espace public, le diagnostic a été relancé et le contrôle de sécurité est redevenu conforme.

Le même principe s’applique aux commandes de test : lorsqu’un ancien essai possède un marquage incomplet, le système le signale au lieu de l’ignorer.

C’est exactement ce que l’on attend d’un mécanisme de recette.

Un bon système de contrôle n’est pas celui qui affiche toujours du vert. C’est celui qui sait empêcher une ouverture lorsqu’il manque une preuve.

Une procédure presque administrative

La recette possède effectivement quelque chose d’administratif.

Chaque contrôle produit un résultat. Celui-ci possède une date, une durée de validité, un statut et parfois des éléments de preuve.

Certaines validations expirent et doivent être exécutées à nouveau.

Une modification importante peut également invalider plusieurs diagnostics précédents.

Il faut alors les repasser.

Cela peut sembler fastidieux, mais la logique est comparable à celle que l’on retrouve dans de nombreux domaines professionnels : avant de mettre un équipement en service, on vérifie que les contrôles réglementaires ou techniques nécessaires sont encore valables.

Une validation obtenue avant une modification importante ne suffit pas nécessairement après cette modification.

On ne « répare » pas l’historique discrètement

Autre principe retenu : les anomalies historiques ne doivent pas être corrigées automatiquement simplement pour obtenir un écran vert.

Lorsqu’une ancienne commande de test présente un marqueur incomplet, le système demande d’abord une analyse en lecture seule, appelée dry-run.

Elle doit déterminer :

ce qui existe → ce qui aurait dû exister → ce qui pourrait être corrigé

Ce n’est qu’après cette analyse qu’une correction éventuelle peut être explicitement autorisée.

Cette méthode permet de conserver une véritable traçabilité.

Une erreur ancienne reste observable jusqu’à ce que l’on puisse expliquer pourquoi et comment elle est corrigée.

La recette protège aussi les utilisateurs

Cette discipline technique a finalement un objectif très concret.

Lorsqu’un adhérent arrivera sur le site, il ne devrait pas avoir à connaître toute cette mécanique.

Il doit simplement pouvoir :

adhérer, payer, retrouver son compte, accéder aux services auxquels il a droit et effectuer ses démarches normalement.

La complexité doit rester derrière l’écran.

La recette consiste précisément à absorber cette complexité avant qu’elle ne devienne un problème pour l’utilisateur.

De « pilote » à « production »

Une vague ne passe donc pas directement de « développée » à « ouverte ».

Elle traverse plusieurs états.

Au stade pilote, quelques parcours contrôlés sont autorisés. On vérifie les comportements réels sans ouvrir encore complètement le service.

Lorsque tous les diagnostics obligatoires sont satisfaits, les tests fonctionnels sont concluants et les mécanismes de sécurité sont opérationnels, la vague peut recevoir son GO de production.

Ce n’est qu’à ce moment-là que l’ouverture générale peut être décidée.

Et si un problème grave apparaît ensuite, la plateforme prévoit également la possibilité de suspendre une fonction ou de revenir à un état antérieur.

Une étape peu spectaculaire, mais essentielle

La partie la plus visible du développement d’un site est souvent la création : nouvelles pages, nouveaux formulaires, nouvelles cartes, nouvelles applications.

La recette est beaucoup moins spectaculaire.

Elle ressemble davantage à une succession de contrôles, de tableaux, de diagnostics et de validations.

Mais c’est probablement l’une des phases les plus importantes du projet.

Car à mesure que le GDSA43 se transforme en véritable plateforme numérique départementale, la question n’est plus seulement :

« Est-ce que cela fonctionne ? »

Elle devient :

« Pouvons-nous démontrer que cela fonctionne correctement, que les données sont protégées, que les erreurs sont détectées et que l’ouverture peut être réalisée sans mettre en danger ce qui existe déjà ? »

C’est toute la différence entre un site que l’on développe et un système que l’on met progressivement en service.

Et c’est précisément le rôle de cette première vague recette.