Distinguer plateforme, site et produit dans OpenSPP

OpenSPP s’exécute sur Odoo, mais la disponibilité d’Odoo ne garantit ni la présence ni l’activation des modules de protection sociale. La mise en œuvre devait donc distinguer image applicative, base créée, schéma migré, modules SP-MIS installés et registre réellement accessible. Cette distinction a guidé les contrôles de santé et les post-conditions.

Odoo peut sélectionner une base à partir de l’hôte demandé. Pour un service public mono-instance, cette souplesse devient un risque de routage et d’administration. Le profil final fixe la base attendue, restreint son filtrage et aligne l’origine canonique sur le domaine Coolify. Nginx transmet ensuite le trafic vers le listener interne sans devenir une seconde source d’URL publique.

Le bootstrap installe les dépendances puis vérifie explicitement les modules attendus. Une réponse HTTP du framework n’est pas utilisée comme preuve d’activation du produit. L’acceptation ouvre le registre, confirme la navigation des composants OpenSPP et observe le worker de file sur une tâche représentative. Cette étape ferme l’écart entre santé de plateforme et disponibilité fonctionnelle.

Les premières révisions ont révélé trois frontières différentes : dépendances Python dans l’image, primitives Compose acceptées par Coolify et contenu Nginx transporté comme fichier géré. Les signes dollar nécessaires à Nginx devaient rester natifs dans ce dernier chemin. Une règle d’échappement issue d’une commande shell aurait corrompu la configuration effective.

PostgreSQL/PostGIS et le filestore Odoo forment le noyau de reprise. Le service de sauvegarde les capture selon une séquence documentée, mais une archive n’est validée qu’après restauration isolée. Le contrôle revient sur la base unique, vérifie les modules OpenSPP, ouvre un enregistrement du registre et confirme que le worker retrouve sa configuration.

L’équipe d’exploitation reçoit une carte des rôles : Nginx pour l’entrée, OpenSPP/Odoo pour le produit, PostgreSQL pour l’état relationnel, le worker pour les tâches et le service de sauvegarde pour les points de reprise. Elle sait où lire chaque journal, comment contrôler l’origine canonique et quelle post-condition examiner après une mise à jour.

Le registre décrit des personnes ou groupes selon des règles d’identité et de relation. Un programme applique ensuite ses propres critères, périodes et décisions. Conserver cette séparation évite qu’une donnée de registre devienne automatiquement une décision d’assistance. Les droits reflètent également ces responsabilités : administration technique, gestion du registre, instruction du programme et contrôle ne disposent pas des mêmes accès.

Une évolution de module est d’abord installée sur une copie représentative. Le test vérifie les migrations, les menus, les règles d’accès, un enregistrement existant et une nouvelle opération. Il observe aussi le worker lorsque la fonction crée une tâche. Cette séquence détecte les régressions qui seraient invisibles dans une simple page de santé et permet de revenir au point de reprise sans toucher au service courant.

Les journaux et métriques suivent disponibilité, erreurs, files, espace disque, durée des sauvegardes et échecs de tâches. Ils n’ont pas besoin de contenir les données personnelles du registre. Les alertes renvoient à une procédure et à un responsable. Une investigation commence par l’identifiant technique de l’opération, puis l’accès au contenu reste limité aux personnes autorisées par le rôle métier.

La version OpenSPP, la branche Odoo, les dépendances Python et les modules installés forment un ensemble. Avant mise à jour, l’équipe compare ce graphe, restaure une sauvegarde et rejoue activation, connexion, registre, tâche de file et origine canonique. Une image précédente ne suffit pas à revenir en arrière si le schéma ou le filestore ont été transformés.

Le premier compte d’administration permet de terminer la configuration, mais il n’est pas destiné à devenir un accès partagé. Après le bootstrap, des comptes nominatifs et des groupes de rôles sont créés, puis le secret initial est protégé ou renouvelé selon le cycle prévu. Le contrôle d’accès est testé avec un profil limité afin de vérifier ce qui reste invisible ou non modifiable.

Un enregistrement peut participer à plusieurs programmes sans que leurs statuts, périodes ou décisions soient confondus. Les modules construisent ces relations et conservent l’historique nécessaire à l’instruction. Les intégrations externes utilisent des identifiants maîtrisés et des échanges documentés. Elles ne copient que les attributs nécessaires au processus destinataire et prévoient le traitement des rejets ou doublons.

Le sidecar de sauvegarde rend l’opération régulière, mais son succès de commande ne suffit pas. Les archives sont chiffrées, externalisées et associées à la version ainsi qu’à la liste des modules. Un exercice périodique recrée les volumes, restaure base et filestore, relance le cycle d’initialisation puis mesure le temps nécessaire pour retrouver un registre utilisable.

Le passage en exploitation est décidé après un déploiement neuf, l’activation SP-MIS, une connexion, la création ou lecture d’un objet, une tâche du worker, un redéploiement et une reprise. Les exceptions restantes sont attribuées à un responsable avec une échéance. Cette décision distingue clairement les fonctions validées du plan d’amélioration, sans réduire le service à la seule disponibilité de sa page d’accueil.

Une évolution du registre ou d’un programme commence par une demande fonctionnelle décrivant les personnes concernées, la règle modifiée et l’effet attendu. La configuration est relue par les responsables métier et données avant d’être installée sur une copie. Les migrations et droits sont testés avec des cas représentatifs, puis la décision est communiquée aux utilisateurs. Cette discipline empêche qu’un ajustement technique change silencieusement l’éligibilité, l’historique ou l’accès aux informations.