En revueBaptiste2026-08-04

Déploiement d'un nouveau client

Procédure d'onboarding technique d'un nouveau client, de l'ouverture du chantier à la fin de la période de rodage.

Cette procédure couvre A2, A3 et B1 à B4. A1 produit un diagnostic et des recommandations ; il suit une démarche de conseil séparée et ne déclenche pas à lui seul un déploiement.

Condition de démarrage

Un chantier peut démarrer lorsque le contrat ou devis correspondant est signé.

Avant tout accès technique ou traitement de données réelles, les éléments suivants sont identifiés :

offre et options souscrites ;
périmètre attendu et exclusions ;
responsable Alpene ;
interlocuteur client ;
actifs, comptes, données et fournisseurs concernés ;
contraintes de sécurité, de localisation et de calendrier ;
éléments attendus du client ;
mode de livraison et suivi éventuel.

L'absence d'une information bloquante est signalée au client. Elle ne doit pas être compensée par une hypothèse silencieuse.

Responsabilités

Chaque client possède un responsable Alpene officiel, même lorsque plusieurs associés interviennent.

Responsabilité	Règle
Pilotage du client	Un responsable Alpene unique tient le périmètre, les décisions et la communication
Interlocuteur client	Une même personne peut cumuler les rôles métier et technique si elle dispose de l'autorité nécessaire
Mise en production des chantiers A	Arthur et Baptiste participent à la validation et à la mise en production
Mise en production des chantiers B	Baptiste valide et conduit la mise en production
Migration de données	Le référent client et Alpene s'alignent explicitement sur le périmètre, le moment de bascule et le résultat
Acceptation	Le client confirme l'alignement après la présentation de livraison

Le responsable Alpene conserve une trace des décisions qui modifient le périmètre, les données, les responsabilités ou la date de mise en production.

Pilotage du chantier

La cible est une instance Plane auto-hébergée par Alpene, avec un projet isolé par client. Le client peut être invité à son projet lorsqu'un accès direct est utile ; aucun client ne doit voir les projets, membres ou documents d'un autre client.

Jusqu'à la mise en service de Plane, le chantier est piloté dans un projet privé GitHub Projects relié aux issues du dépôt concerné.

Le suivi minimum comporte :

périmètre et exclusions ;
tâches et responsable ;
décisions ;
dépendances et éléments attendus du client ;
risques et blocages ;
date ou fenêtre de mise en production ;
livrables ;
éléments reportés après livraison.

Plane est un produit sous licence AGPL-3.0. Alpene peut l'utiliser et l'auto-héberger. Toute modification du produit proposée aux utilisateurs via le réseau doit respecter les obligations de cette licence.

Qualification de Plane

Le pilote local valide Plane Community Edition comme cible de gestion de projet interne, avec accès client optionnel.

Le test a utilisé Colima, quatre processeurs virtuels, 8 Gio de mémoire et le fichier Docker Compose officiel sur architecture ARM64. Il a confirmé :

le démarrage de la stack stable et de ses douze services ;
une page d'accueil et une API répondant en HTTP 200 ;
environ 1,2 Gio de mémoire utilisée au repos ;
une restauration logique PostgreSQL réussie après sauvegarde avec pg_dump ;
la compatibilité de l'édition communautaire avec l'auto-hébergement sous licence AGPL-3.0.

Deux précautions ont été identifiées :

lorsque les mots de passe par défaut sont remplacés, DATABASE_URL et AMQP_URL doivent être renseignées explicitement afin d'éviter une incohérence avec les services PostgreSQL et RabbitMQ ;
la collecte anonyme d'événements est proposée activée dans l'écran initial et doit être désactivée lorsque cette collecte n'est pas retenue.

La documentation produit confirme qu'un client invité comme Guest ne voit que les projets auxquels il est explicitement ajouté. Un Guest ne peut recevoir que les rôles Guest ou Commenter dans un projet. Les administrateurs Alpene du workspace conservent un accès transverse.

Le modèle cible utilise donc un projet privé par client et le rôle le plus faible compatible avec le besoin. Une instance séparée est utilisée lorsqu'une isolation applicative dans un workspace partagé ne suffit pas.

La sauvegarde de référence ne repose pas uniquement sur la copie à chaud des volumes proposée par le script officiel. Elle couvre un export logique PostgreSQL, le stockage objet et les fichiers de configuration, puis fait l'objet d'un test de restauration. Les work items restent exportables en CSV, Excel ou JSON.

Les fonctions avancées de SSO, OIDC, SAML, gouvernance et conformité dépendent de l'édition retenue et sont qualifiées uniquement lorsqu'elles entrent dans le périmètre du déploiement.

Réunion de lancement

Une réunion formelle de lancement n'est pas obligatoire pour un chantier simple. Le cadrage peut être confirmé par écrit et lors des échanges de travail.

Une réunion de lancement devient obligatoire lorsque le chantier comporte au moins un des éléments suivants :

plusieurs équipes ou décideurs ;
migration ou interruption de service ;
données sensibles ;
intégrations avec plusieurs systèmes ;
environnement STG ;
déplacement ou intervention coordonnée ;
dépendance forte à un prestataire tiers ;
risque opérationnel significatif.

Le lancement confirme au minimum le périmètre, les interlocuteurs, les prérequis, les risques et la méthode de validation.

Propriété des comptes et des actifs

Les actifs structurants sont créés au nom du client dès que le fournisseur et le modèle d'exploitation le permettent :

domaine et registrar ;
tenant de collaboration et d'identité ;
licences et abonnements métier ;
comptes administrateurs client ;
données et espaces documentaires ;
comptes constructeur et garanties.

Alpene utilise des accès délégués, nominatifs et révocables. Les comptes partagés sont interdits, à l'exception d'un compte de secours explicitement documenté et protégé.

Le code peut être développé dans un dépôt Git privé Alpene pendant le chantier et le suivi. Si le client possède déjà une organisation GitHub, le dépôt peut être créé directement chez lui avec un accès Alpene. Dans tous les cas, le code livré appartient au client et reste transférable conformément à Titularité des comptes.

L'hébergement mutualisé et les comptes d'inférence peuvent rester au nom d'Alpene lorsque le client souscrit le suivi correspondant. Le périmètre restituable et le mode de sortie sont documentés dès le déploiement.

Accès et secrets

Avant de demander un nouvel accès, Alpene vérifie qu'un accès délégué ou un groupe existant ne couvre pas déjà le besoin.

Chaque accès est nominatif.
Le MFA est activé pour les comptes administrateurs.
Les secrets partagés sont conservés dans Bitwarden.
Les secrets applicatifs sont injectés par variables d'environnement ou mécanisme dédié.
Aucun secret n'est stocké dans Git, une issue, un document de réunion ou une messagerie non prévue à cet effet.
Les accès temporaires possèdent une date de revue ou d'expiration.
Un inventaire des administrateurs est remis au client.

Environnements

Le nombre d'environnements reste proportionné au risque du chantier.

Environnement	Usage	Règle
DEV	Développement local	Données fictives, synthétiques ou anonymisées
Preview	Vérification d'une branche ou pull request	Référence B1 avec Netlify ; aucune donnée de production
STG	Préproduction proche de la production	Référence B2 ; A2/A3 uniquement lorsque les données, intégrations ou migrations le justifient
PROD	Service utilisé par le client	Accès restreints, sauvegarde, supervision et procédure de rollback

Un environnement INT séparé n'est pas créé par défaut. Pour la taille actuelle d'Alpene, il ferait généralement doublon avec DEV, les previews et STG.

B1 utilise les previews de Netlify avant production. B2 dispose d'un environnement STG sauf si l'application est exceptionnellement simple et sans donnée sensible ni migration. A2 et A3 utilisent STG lorsqu'un test sur des intégrations réalistes ou une bascule contrôlée est nécessaire.

Provisionnement de l'infrastructure

OpenTofu ou Terraform ne sont pas imposés dans la baseline. Leur complexité n'est pas justifiée pour un déploiement ponctuel et simple.

Le provisionnement est acceptable lorsqu'il est :

reproductible à partir du dépôt et de la documentation ;
exécuté avec des comptes nominatifs ;
relu avant production ;
accompagné d'un inventaire des ressources ;
accompagné d'une procédure de sauvegarde et de suppression.

Les applications conteneurisées utilisent Docker Compose lorsque plusieurs services doivent être déployés ensemble. Les services managés comme Netlify, Scaleway Object Storage ou Microsoft 365 sont configurés dans leurs interfaces ou API, avec les paramètres structurants consignés dans le dépôt.

Un outil d'infrastructure as code pourra être introduit plus tard lorsqu'un même socle devra être reproduit pour plusieurs clients. Il fera alors l'objet d'une décision et d'un modèle validé, pas d'une obligation rétroactive.

Déroulement transverse

1. Ouverture

enregistrer le contrat signé et les offres concernées ;
nommer le responsable Alpene ;
identifier l'interlocuteur client ;
créer le projet de suivi ;
reprendre le périmètre, les exclusions et les livrables ;
lister les éléments attendus du client.

2. Inventaire

comptes, domaines, dépôts et fournisseurs ;
applications, données et intégrations ;
utilisateurs, groupes et administrateurs ;
environnement existant ;
sauvegardes et moyens de retour arrière ;
contraintes de sécurité et de localisation ;
dépendances contractuelles ou techniques.

L'inventaire est proportionné au chantier. B4 peut se limiter au matériel et à l'environnement immédiat ; B2, A2, A3 ou une migration demandent un inventaire plus complet.

3. Conception du déploiement

Le responsable définit :

architecture cible ;
flux de données ;
propriétaires des comptes ;
environnements nécessaires ;
accès et secrets ;
sauvegarde et rollback ;
supervision ;
séquence de mise en production ;
critères de contrôle et de présentation.

Tout choix qui contredit une stack de référence est motivé dans le chantier. Une décision structurante et réutilisable doit ensuite faire l'objet d'un ADR.

4. Réalisation

créer les comptes et ressources ;
développer ou configurer dans DEV ;
versionner le code et les paramètres non secrets ;
vérifier les sauvegardes ;
exécuter les contrôles automatisés disponibles ;
préparer la documentation au fil du chantier ;
déployer en preview ou STG lorsque prévu.

5. Contrôle interne

Avant présentation au client :

vérifier le périmètre convenu ;
contrôler les parcours principaux et les cas d'erreur ;
vérifier les droits et accès administrateurs ;
vérifier qu'aucun secret n'est exposé ;
contrôler sauvegarde et rollback ;
vérifier supervision et alertes ;
préparer les éléments de livraison ;
consigner les limitations connues.

6. Présentation et alignement

Il n'existe pas de recette formelle systématique. Alpene présente le résultat au client et recueille ses observations.

Les corrections nécessaires pour respecter le périmètre convenu sont réalisées avant ou pendant la période de rodage. Une nouvelle fonctionnalité, une nouvelle intégration ou un changement de périmètre est enregistré séparément ; il ne devient pas implicitement une correction de livraison.

L'alignement final est tracé par un compte rendu, une issue validée ou un message écrit du client.

7. Mise en production

confirmer la fenêtre avec le client ;
vérifier la dernière sauvegarde ou l'export de sécurité ;
annoncer le début de l'intervention ;
appliquer les changements dans l'ordre prévu ;
exécuter les migrations ;
réaliser les contrôles de santé ;
tester les parcours critiques ;
activer la supervision ;
annoncer la fin de l'intervention ;
conserver la capacité de rollback pendant la stabilisation.

Une migration de données fait l'objet d'un go/no-go conjoint entre le client et Alpene. Le contrôle porte sur les volumes, relations, droits et cas métier représentatifs, pas seulement sur l'absence d'erreur technique.

8. Livraison obligatoire

Chaque chantier se termine par une session de livraison, même si aucun kick-off formel n'a eu lieu.

La session couvre :

démonstration du résultat ;
accès et rôles ;
opérations courantes ;
sauvegarde et récupération ;
support et signalement d'incident ;
limites connues ;
éléments remis ;
prochaines actions ;
conditions de la période de rodage.

9. Rodage

Les deux semaines suivant la mise en production constituent la période de rodage.

Sont inclus :

correction d'un comportement non conforme au périmètre convenu ;
réglage mineur de configuration ;
correction d'une erreur de données provoquée par le déploiement ;
accompagnement sur les premiers usages ;
ajustement raisonnable d'un message, seuil ou paramètre existant.

Ne sont pas inclus implicitement :

nouvelle fonctionnalité ;
nouvelle source, étape, sortie ou intégration ;
extension du nombre d'utilisateurs ou du périmètre métier ;
migration supplémentaire ;
changement de fournisseur ou d'architecture ;
formation ou accompagnement non prévu.

À la fin du rodage, les anomalies restantes et évolutions proposées sont consignées. Le chantier passe alors au suivi récurrent ou à l'exploitation par le client.

Checklist B1 : Site vitrine

Checklist B2 : Plateforme

Checklist B3 : Socle IT

Checklist B4 : Matériel et intervention

Checklist A2 : Agents et automatisation

Checklist A3 : Chat IA souverain

Contrôles de fin de déploiement

Contrôle	Résultat attendu
Périmètre	Les éléments livrés et exclus sont explicitement listés
Propriété	Les titulaires, administrateurs, facturations et accès délégués sont connus
Fonctionnel	Les parcours critiques sont démontrés sans erreur bloquante
Sécurité	MFA administrateur, secrets, droits et exposition réseau sont vérifiés
Données	Localisation, sauvegarde, rétention, export et suppression sont documentés
Exploitation	Supervision, alertes, logs, support et rollback sont opérationnels
Réversibilité	Le client peut récupérer les sources, données, comptes et documentation prévus
Documentation	Les procédures d'usage et d'administration correspondent au déploiement réel
Rodage	La date de début, la date de fin et le périmètre des corrections sont communiqués

Un contrôle non applicable est marqué comme tel avec une justification. Un contrôle critique non conforme bloque la mise en production ou fait l'objet d'une acceptation explicite et temporaire du risque.

Éléments remis au client

Selon l'offre, le dossier de livraison contient :

résumé du périmètre livré ;
architecture et flux principaux ;
liste des fournisseurs et régions de traitement ;
inventaire des comptes, groupes et administrateurs ;
accès ou procédure de récupération ;
dépôt de code ou droit de transfert ;
configuration et variables attendues, sans secret exposé ;
inventaire des données et sauvegardes ;
procédures de déploiement, rollback et restauration ;
guide administrateur ;
guide utilisateur ;
limites connues et exceptions acceptées ;
procédure de support et de sortie.

Les éléments sensibles sont transmis via Bitwarden ou un canal adapté, jamais directement dans le document de livraison.

Passage au suivi

Lorsque le client souscrit un suivi, le responsable Alpene transmet au dispositif d'exploitation :

périmètre supervisé ;
services, environnements et dépendances ;
alertes et destinataires ;
sauvegardes et dernière restauration testée ;
administrateurs et accès de secours ;
incidents connus ;
échéances et revues périodiques ;
éléments exclus du support.

Sans suivi, les accès Alpene sont révoqués après la livraison et le rodage, sauf accord écrit différent. Le client reçoit les éléments nécessaires pour exploiter le service ou les transmettre à un autre prestataire.

Décisions validées

Le contrat ou devis signé autorise l'ouverture du chantier.
Un responsable Alpene unique est nommé par client.
Arthur et Baptiste valident les mises en production A ; Baptiste valide les mises en production B.
Un interlocuteur client peut cumuler les responsabilités métier et technique.
La réunion de livraison est obligatoire ; le kick-off formel est réservé aux projets qui le justifient.
La validation repose sur une présentation et un alignement tracé avec le client, sans recette formelle systématique.
Une migration nécessite un go/no-go conjoint entre le client et Alpene.
Les previews suffisent pour B1 ; STG est la référence B2 et reste conditionnel pour A2/A3.
OpenTofu et Terraform ne sont pas imposés ; la reproductibilité repose d'abord sur Git, Docker Compose et une procédure documentée.
Les deux semaines suivant la mise en production constituent la période de rodage.

Condition de démarrage​

Responsabilités​

Pilotage du chantier​

Qualification de Plane​

Réunion de lancement​

Propriété des comptes et des actifs​

Accès et secrets​

Environnements​

Provisionnement de l'infrastructure​

Déroulement transverse​

1. Ouverture​

2. Inventaire​

3. Conception du déploiement​

4. Réalisation​

5. Contrôle interne​

6. Présentation et alignement​

7. Mise en production​

8. Livraison obligatoire​

9. Rodage​

Checklist B1 : Site vitrine​

Checklist B2 : Plateforme​

Checklist B3 : Socle IT​

Checklist B4 : Matériel et intervention​

Checklist A2 : Agents et automatisation​

Checklist A3 : Chat IA souverain​

Contrôles de fin de déploiement​

Éléments remis au client​

Passage au suivi​

Décisions validées​