Le problème opérationnel.
La gestion des stages ne se résume pas à un tableau de bord. Une école coordonne des cohortes, des élèves, des organismes, des tuteurs, des dates, des heures, des suivis et des justificatifs signés. Chaque rôle a besoin d’une vue différente du même dossier, et une correction ne doit pas effacer ce qui l’a précédée.
L’ancienne implémentation scolaire ne pouvait pas servir de base à un produit. J’ai reconstruit VECTOR depuis zéro en ne gardant que la compréhension du métier. Aucun code historique, dossier personnel, nom ou asset de l’ancien projet n’a été repris dans le nouveau dépôt.
Ce qu’un système maîtrisé par l’école doit garantir.
L’architecture part de quatre contraintes concrètes :
- Chaque installation appartient à une seule école, qui contrôle sa base, son identité visuelle, ses sauvegardes et son déploiement.
- Les droits et le périmètre des tuteurs doivent être appliqués par le serveur avant toute sélection, tout comptage ou tout export.
- Chaque stage garde la version du programme qui a fixé heures, suivis et justificatifs ; les corrections préservent le dossier opérationnel initial.
- Imports, exports, rétention et restauration doivent être bornés, vérifiables et relançables sans risque après un échec.
Définir d’abord la frontière de propriété.
Déplacer davantage d’état dans le navigateur aurait laissé les questions difficiles intactes. Les contrôles de rôle auraient pu rester cachés dans l’interface, toute l’école être chargée en mémoire et un champ modifié être traité comme si sa valeur précédente n’avait jamais existé.
VECTOR consacre chaque installation à une seule école au lieu de construire un service multi-tenant partagé. La responsabilité opérationnelle est nette, et les sauvegardes, la rétention et le white label restent plus simples à raisonner. Le projet distribue un logiciel, pas une plateforme cloud administrée.
Un serveur compact aux frontières explicites.
L’espace web appelle une API Express qui gère authentification, rôles, versions de programme et transitions. SQLite conserve les dossiers en WAL. Des curseurs AES-GCM lient couverture et attention à l’école, au rôle, aux filtres et à une position stable sans en révéler le contenu.
Pourquoi ces technologies.
La stack est dimensionnée pour une école qui possède et exploite sa propre installation.
Une école par installation.
- Pourquoi
- Propriété des données, rôles, white label, sauvegarde et restauration restent dans une frontière institutionnelle claire.
- Ce que j’ai écarté
- Un SaaS multi-tenant exigerait isolation des clients, facturation, opérations centrales et garanties de conformité qui ne relèvent pas du produit.
- Ce que cela a coûté
- Nous acceptons que chaque école gère les mises à jour, la capacité et les sauvegardes de son instance.
Express comme couche serveur.
- Pourquoi
- Authentification, rôles, périmètre et transitions s’appliquent avant que les données n’atteignent le navigateur.
- Ce que j’ai écarté
- Une application uniquement web laisserait règles et données au client, qui ne peut pas imposer des autorisations fiables.
- Ce que cela a coûté
- Nous acceptons de déployer et maintenir un service serveur sur le réseau de l’établissement.
SQLite en mode WAL avec migrations.
- Pourquoi
- Transactions, portabilité et snapshots d’un fichier unique sont proportionnés à la charge d’une seule école.
- Ce que j’ai écarté
- PostgreSQL ou une base cloud ajouteraient service, identifiants et administration sans échelle multi-tenant démontrée.
- Ce que cela a coûté
- Nous acceptons les limites d’écriture concurrente et l’absence de haute disponibilité automatique.
Docker avec des outils explicites de sauvegarde et restauration.
- Pourquoi
- L’établissement obtient une installation reproductible et un parcours de reprise vérifiable sur sa propre infrastructure.
- Ce que j’ai écarté
- Une plateforme gérée simplifierait les opérations, mais déplacerait le contrôle et la dépendance vers un fournisseur.
- Ce que cela a coûté
- Nous acceptons que l’opérateur surveille le stockage, teste les restaurations et planifie les mises à jour.
Les choix qui sécurisent le travail quotidien.
Le produit préfère des règles visibles à un état caché mais pratique.
Versionner les règles, pas seulement le stage
Une version de programme publiée est immuable. Les nouvelles règles valent pour les nouvelles affectations ; un stage existant garde heures cibles, minimum de suivis et justificatifs de son départ.
Le compromisUne correction exige une nouvelle version et une réaffectation explicite des stages intacts. La fin d’un stage ne change jamais rétroactivement.
Montrer les trous avant qu’ils deviennent des exceptions
La couverture est calculée par cohorte et période et distingue affectation valide, absence et chevauchement. Une ligne non couverte ouvre un stage prérempli sans perdre le contexte.
Le compromisLa vue reste volontairement opérationnelle, pas un moteur de reporting général. Elle reste ainsi actionnable et correcte pour chaque rôle.
Dériver l’attention des dossiers déjà possédés
La file déduit le travail à faire des justificatifs, heures, dates et tuteurs au lieu de maintenir une seconde liste. Le serveur applique le rôle avant comptage et pagination.
Le compromisLa file n’accepte pas de rappels arbitraires : elle reste cohérente avec le dossier de stage et évite une seconde source de vérité.
Auto-hébergement et restauration.
Chaque école peut définir nom, couleurs, logo et coordonnées de support avec des révisions qui protègent les modifications concurrentes. L’image Alpine avec Node 24 épinglé s’exécute sans privilège, avec code applicatif détenu par root, sans gestionnaire de paquets et avec un système de fichiers racine en lecture seule. Health et doctor bloquent le démarrage si configuration, schéma ou propriété du stockage sont dangereux.
Les outils créent un instantané SQLite privé à taille bornée, l’inspectent sans démarrer l’application et le restaurent par un parcours protégé qui détecte remplacement du chemin et modification de la source. L’automatisation analyse conteneur et sources pour détecter vulnérabilités et secrets, publie un SBOM, construit deux fois l’archive et valide le parcours d’acceptation extrait avant publication.
Ce que VECTOR prend en charge aujourd’hui.
Une école peut publier ses règles, contrôler la couverture d’une cohorte, créer un stage depuis un trou de planification et traiter une file par rôle. Le même dossier conserve heures, suivis, historique des preuves, audit, import atomique, export filtré et rétention gouvernée.
VECTOR est un logiciel open source auto-hébergé. Ce n’est pas un SaaS administré et il ne revendique ni certification de conformité, ni haute disponibilité, ni SSO. Une institution qui en a besoin devra encore traiter ces sujets côté produit et déploiement.
Registre des preuves.
La release signée 3.4.0 rattache ses promesses produit à des contrôles concrets :
- Politique de programme
- Les coordinateurs publient des versions immuables avec heures cibles, minimum de suivis et justificatifs requis. Les stages existants gardent leur version.
- Opérations bornées
- Pagination indexée et stable pour élèves et organismes, validation groupée des imports et limites de capacité en base maintiennent listes, historique des stages, sessions et annuaire administratif dans des enveloppes explicites.
- Stockage et restauration
- Démarrage, doctor, sauvegarde, inspection, compactage et restauration refusent les alias SQLite non sûrs et les dérives de schéma, vérifient les fichiers WAL associés et effectuent les contrôles d’intégrité et les instantanés sur la même connexion protégée qu’ils ont ouverte.
- Frontière des requêtes et sessions
- Origines de production exactes, échecs de connexion neutres quant à l’identité, refus des cookies dupliqués, contrôles CSRF résistants aux attaques temporelles et plafond de dix sessions s’appliquent avant que l’espace par rôle n’expose les dossiers scolaires.
- Vérification et release
- Les gates Node 22 et 24, l’acceptation Chromium et WebKit, les seuils de couverture native, les répétitions de charge et CRUD, les scans Trivy et deux builds identiques octet par octet protègent la release. Le tag signé vérifié pointe vers le commit fb802e5 et la release GitHub immuable publie huit artefacts liés par digest, dont son SBOM CycloneDX.
Version publiée vérifiée v3.4.0 Vérification du
Cette étude décrit la release immuable 3.4.0 et ses contrôles d’auto-hébergement au commit fb802e5. GitHub Pages est un tour du produit ; l’application opérationnelle s’exécute depuis le paquet serveur. Aucun dossier réel, aucune intégration institutionnelle ni aucun résultat n’y sont représentés, et la release ne revendique ni disponibilité gérée ni certification de conformité.