Plateforme / outil métier (B2)

En bref

Cette offre crée un outil en ligne adapté à un besoin métier précis, par exemple un portail client, un espace pour les équipes ou un outil de gestion interne. Le but est de remplacer un fonctionnement manuel ou dispersé par un service simple, partagé et adapté aux règles de l'organisation. Le suivi mensuel associé, appelé suivi C dans le catalogue, couvre l'hébergement, la maintenance, le support et de petites évolutions.

Stack de référence de l'offre B2 et de ses options (B2.1 à B2.5).

Périmètre

B2 couvre le développement d'un outil web ciblé : portail client, outil RH, back-office, extranet ou application interne répondant à un processus clairement délimité.

La baseline comprend :

• conception et développement du périmètre convenu ;
• comptes utilisateurs et gestion des accès de base ;
• stockage des données métier ;
• journalisation technique ;
• sauvegardes ;
• documentation et prise en main ;
• mise en production et maintien dans le cadre du suivi associé.

B2 ne couvre pas la construction d'un ERP généraliste ni le remplacement sans limite d'un système d'information complet. Lorsqu'une solution du marché couvre correctement le besoin, son intégration est privilégiée conformément au principe d'agnosticisme.

Choix du framework

Astro reste la référence pour les sites centrés sur le contenu, notamment B1. Il peut convenir à un portail simple avec peu d'interactions, mais ce n'est pas la référence B2 pour une application authentifiée riche en formulaires, états et règles métier.

La stack de référence pour B2 est un monolithe Next.js avec TypeScript :

• une base de code pour l'interface et les endpoints serveur ;
• rendu serveur et composants interactifs dans le même projet ;
• déploiement simple pour les petits outils métier ;
• possibilité d'extraire une API ou un worker lorsque le besoin apparaît.

Le choix est réévalué si le projet nécessite une application mobile, des traitements intensifs, une API publique indépendante ou une architecture déjà imposée par le client.

Stack de référence

Brique	Référence	Règle
Application	Next.js avec TypeScript	Monolithe modulaire par défaut
Interface	React, rendu serveur et composants client ciblés	Pas de SPA globale sans besoin démontré
Validation	Zod	Même schéma utilisé aux frontières serveur et client lorsque possible
Base de données	PostgreSQL	Une base ou des identifiants séparés par client
Accès aux données	Drizzle ORM et migrations versionnées	Aucun changement manuel du schéma en production
Fichiers	Stockage compatible S3	Pas de fichiers métier persistants dans le conteneur applicatif
Cache et tâches	Redis et worker séparé uniquement si nécessaire	Aucune dépendance ajoutée sans besoin mesuré
Tests unitaires	Vitest	Règles métier et transformations sensibles
Tests de parcours	Playwright	Authentification et parcours critiques
Conteneurisation	Docker	Image reproductible entre préproduction et production
Intégration continue	GitHub Actions	Vérifications, tests et build avant déploiement

L'application est structurée par domaines métier plutôt que par types techniques globaux. Les règles métier ne résident pas uniquement dans les composants React ou les handlers HTTP : elles restent testables indépendamment de l'interface.

Architecture de déploiement

Par défaut, chaque client dispose d'un environnement applicatif et d'identifiants de base de données séparés. Une architecture multi-tenant n'est retenue que si le produit et le modèle d'exploitation la justifient explicitement.

Environnement	Usage
Local	Développement avec données fictives ou anonymisées
Préproduction	Validation fonctionnelle, migrations et tests de livraison
Production	Données réelles, accès restreints et supervision active

Les déploiements sont automatisés. Une mise en production comprend l'application des migrations, un contrôle de santé et la possibilité de revenir à l'image précédente. Une migration destructive nécessite une sauvegarde vérifiée et une procédure de retour arrière spécifique.

Authentification et autorisation

La baseline fournit des comptes nominatifs et des rôles adaptés au périmètre. Les règles suivantes s'appliquent :

• aucun compte partagé ;
• mots de passe non stockés en clair ;
• MFA activé lorsque le mécanisme d'identité le permet ;
• contrôle des autorisations côté serveur pour chaque opération sensible ;
• révocation documentée ;
• compte administrateur de secours protégé ;
• limitation des tentatives et des sessions anormales.

Lorsque le client possède un IdP, l'authentification fédérée par OpenID Connect ou SAML est privilégiée et relève de B2.2. L'application ne duplique pas les comptes du client au-delà des informations nécessaires aux rôles et à l'audit.

Lorsqu'aucun IdP n'existe, la référence Alpene est Authentik, auto-hébergé et administré avec des comptes, groupes et politiques propres au client.

Données et fichiers

• Le schéma PostgreSQL est versionné avec l'application.
• Les contraintes d'intégrité sont appliquées en base, pas uniquement dans l'interface.
• Les données sensibles sont identifiées pendant le cadrage.
• Les environnements de développement n'utilisent pas de copie brute de la production.
• Les fichiers sont stockés dans Scaleway Object Storage, via son interface compatible S3, dans un espace séparé par client.
• Les exports utilisent des formats documentés et réutilisables.
• La suppression logique ou physique est définie selon le besoin métier et les obligations de conservation.

Journalisation et audit

Les logs techniques permettent de diagnostiquer les erreurs sans enregistrer inutilement les données métier. Ils comportent au minimum :

• identifiant de requête ;
• environnement et version déployée ;
• type d'événement ;
• statut et durée ;
• identifiant utilisateur pseudonymisé lorsque nécessaire ;
• erreur structurée sans secret ni contenu sensible.

Un journal d'audit métier est ajouté lorsque le risque le justifie : connexion, modification de droits, export, suppression ou changement d'un objet sensible. Sa durée de conservation est distincte de celle des logs techniques.

L'instrumentation suit les conventions OpenTelemetry afin de ne pas dépendre d'un fournisseur unique. Le collecteur central alimente Prometheus pour les métriques, Loki pour les logs, Tempo pour les traces et Grafana pour la consultation et les alertes. Les règles d'exploitation sont détaillées dans Supervision et astreinte.

Sauvegardes et restauration

• Sauvegarde automatique de PostgreSQL et du stockage de fichiers.
• Chiffrement et accès restreint aux sauvegardes.
• Rétention définie avec le client selon la criticité des données.
• Restauration testée avant livraison puis selon la procédure d'exploitation.
• Sauvegarde préalable à toute migration destructive.
• Documentation des objectifs de perte de données et de délai de restauration.

La baseline vise un RPO de 24 heures et un RTO de 8 heures ouvrées. Ces objectifs deviennent contractuels uniquement après validation dans le cadrage. Un besoin plus strict entraîne un dimensionnement et une procédure spécifiques.

La politique transverse est définie dans Sauvegarde et restauration.

Sécurité applicative

• Validation serveur de toutes les entrées.
• Requêtes paramétrées via la couche d'accès aux données.
• Protection contre les attaques web courantes selon l'OWASP.
• Autorisations contrôlées côté serveur, y compris sur les exports et fichiers.
• Secrets fournis par l'environnement et jamais stockés dans Git.
• Dépendances surveillées et correctifs critiques appliqués avant livraison.
• En-têtes de sécurité et politique CSP adaptés à l'application.
• Limitation de débit sur les endpoints sensibles et intégrations externes.

Les exigences minimales sont complétées par Sécurité par défaut.

Cadrage fonctionnel (B2.1)

Le cadrage produit un dossier court, validé avant le développement :

1. utilisateurs et rôles ;
2. processus actuel et résultat attendu ;
3. parcours principaux ;
4. données manipulées et niveau de sensibilité ;
5. intégrations externes ;
6. règles métier et cas d'erreur ;
7. périmètre de la première livraison ;
8. critères d'acceptation ;
9. contraintes de reprise, d'exploitation et de sortie.

Le résultat comprend des écrans ou flux suffisamment précis pour estimer et construire. Les points non inclus sont listés explicitement afin d'éviter que la baseline soit interprétée comme un périmètre ouvert.

SSO (B2.2)

L'option B2.2 connecte la plateforme à l'IdP du client :

• choix du protocole pris en charge ;
• correspondance des utilisateurs et rôles ;
• gestion de la création et de la révocation ;
• test de connexion, déconnexion et expiration ;
• procédure de secours documentée.

L'intégration est coordonnée avec B3.1 lorsque le SSO du client est déployé par Alpene.

Intégration tierce (B2.3)

Chaque connecteur dispose de :

• propriétaire des identifiants ;
• périmètre des données échangées ;
• limites de débit ;
• stratégie de retry et d'idempotence ;
• traitement des erreurs ;
• journalisation ;
• comportement en cas d'indisponibilité ;
• procédure de révocation.

Les appels externes sont isolés derrière un module propre afin de pouvoir changer de fournisseur sans réécrire les règles métier.

Reprise de données (B2.4)

La reprise comprend selon le périmètre : inventaire, export, nettoyage, mapping, import, contrôle d'échantillons, journal des rejets et validation finale.

Les scripts de reprise sont versionnés et rejouables. Un import n'est pas considéré comme validé sur le seul nombre de lignes : les totaux, relations et cas représentatifs sont contrôlés avec le client.

Modules additionnels (B2.5)

Un module additionnel étend le périmètre fonctionnel sans remettre en cause l'architecture de base. Il possède ses propres critères d'acceptation, migrations, tests, règles d'accès et documentation.

Une extension qui transforme l'outil en ERP ou introduit un nouveau produit autonome déclenche un nouveau cadrage plutôt qu'un simple module.

Livraison

Chaque plateforme B2 est livrée avec :

• dépôt Git et historique ;
• architecture et procédure de développement ;
• schéma de données et migrations ;
• inventaire des services tiers ;
• accès administrateurs et procédure de gestion des utilisateurs ;
• procédure de déploiement, sauvegarde, restauration et rollback ;
• guide utilisateur et session de prise en main ;
• procédure d'export et de réversibilité.

Décisions validées

• Next.js et TypeScript constituent la stack B2 de référence ; Astro reste réservé aux portails principalement éditoriaux.
• Drizzle ORM est la couche d'accès standard à PostgreSQL.
• Authentik est l'IdP de référence lorsqu'un client ne possède pas de fournisseur d'identité.
• Scaleway Object Storage est le stockage de fichiers compatible S3 de référence.
• OpenTelemetry, Prometheus, Loki, Tempo et Grafana constituent le socle d'observabilité.
• La baseline vise un RPO de 24 heures et un RTO de 8 heures ouvrées, à confirmer contractuellement pendant le cadrage.