Intégrer une application — le Golden Path

Vous êtes ici : Guides — faire naître une nouvelle application dans la suite. Le chemin pavé (« Golden Path ») qu’une nouvelle application suit pour naître dans l’écosystème — de la première décision au dogfood en production. Lecture 8 min. Audience : devs, intégrateurs, auditeurs. Date : 2026-07-08 | Version : 1.0 — créée après le test à blanc de l’audit 360 (une app fantôme scaffoldée en suivant uniquement la doc ; chaque devinette rencontrée a été comblée avant d’écrire cette page)

Le principe central — la route pavée, pas le sentier

Une app GS-Apps ne « s’ajoute » pas au dépôt : elle naît dans une infrastructure qui l’attend. Gabarits copiables, checklist ordonnée, et une batterie de contrôles automatiques qui refusent ce qui dévie. Le critère de qualité du chemin est mesurable : un agent (humain ou IA) qui n’a jamais vu le dépôt doit produire une app conforme en suivant uniquement la documentation. Ce critère est testé — littéralement — en scaffoldant une app jetable sans connaissance implicite.

TL;DR

Question	Réponse	Détail
Par où on commence ?	Par les décisions de naissance (nom, domaine, surface publique ?) — pas par le code	Phase 0
Et ensuite ?	Les données d’abord : schéma dédié, isolation par compagnie dormante, câblage au catalogue	Phase 1
Le code, on le copie d’où ?	De gabarits versionnés (serveur, auth, frontend, workflow) — jamais d’une autre app à l’aveugle	Phase 2
Qui donne les accès ?	Un manifeste de permissions versionné + une étape humaine explicite pour l’identité base de données	Phase 3
Le déploiement ?	Workflow gabarit (dormant tant que l’infra n’existe pas) + provisioning scripté avec arrêts humains	Phase 4
C’est fini quand ?	Quand l’isolation est activée, la tuile Hub posée, la doc écrite et l’app dogfoodée	Phase 5

Le pipeline en une image

Six phases, des gates à chaque jonction, et deux arrêts humains délibérés — l’automatisation s’arrête là où la décision d’accès commence.

Phase 0 — Décider avant de coder

Quatre décisions précèdent la première ligne : le nom et le domaine métier (chaque app possède son schéma de données dédié — aucun partage de tables entre domaines), l’arbitrage entre rejoindre un conteneur existant ou naître app autonome, la présence éventuelle d’une surface publique (qui déclenche des règles durcies — voir Sécurité), et le rattachement à l’inscription d’identité partagée (une nouvelle app n’exige pas de nouvelle inscription Entra : son URL de redirection s’ajoute à l’inscription commune lors du provisionnement).

Phase 1 — Les données d’abord

L’ordre est contre-intuitif et volontaire : le schéma naît avant le code. Le gabarit de migration impose d’office le socle : colonnes standard (identifiant, compagnie, horodatage, suppression logique), isolation par compagnie créée dormante (la politique RLS existe dès le premier jour, elle sera activée en phase 5), index préfixés par la compagnie. La nouvelle table est déclarée dans le même commit au catalogue de lignage et au registre des schémas approuvés — deux contrôles bloquants le vérifient. Le processus complet des migrations (numérotation, idempotence, retour arrière) est un standard écrit et outillé : chaque vague est rejouée sur une base jetable deux fois (preuve d’idempotence) puis par-dessus une copie conforme de la production.

Phase 2 — Le code, depuis les gabarits

Le squelette entier vient de gabarits versionnés : serveur Express avec les protections d’en-têtes et la politique CSP construite par une fonction partagée (jamais copiée-collée), middleware d’authentification qui valide les jetons et résout les rôles par compagnie, frontend avec connexion Microsoft, bilinguisme FR/EN câblé dès la première vue, et design system commun. Les bibliothèques partagées (@gs/* — 17 paquets : config validée, accès données avec contexte de compagnie, client HTTP avec relance automatique, télémétrie, journalisation structurée…) font qu’une app nouvelle hérite des correctifs de toutes les autres. Les fournisseurs externes (courriel, SMS, paiements) suivent un patron unique : interface métier + implémentation neutre tant que la ressource n’est pas provisionnée — l’app se déploie avant que le fournisseur existe.

Pourquoi des gabarits et pas « copier l'app d'à côté » ?

Le test à blanc de juillet 2026 l’a mesuré : quand la consigne était « copiez depuis telle app », l’agent héritait des spécificités de cette app (dépendances qui n’avaient rien à faire là, patterns d’une génération antérieure). Les gabarits sont neutres, commentés, et testés par le même exercice qui les a corrigés.

Phase 3 — Permissions et identités

Les droits de l’app sur la base sont déclarés dans un manifeste versionné — quel schéma, quelles opérations, rien de plus. La création de l’identité base de données correspondante est le premier arrêt humain : la migration est écrite par l’outillage, mais son application reste un acte d’administrateur, hors de tout chemin automatique. Le bootstrap du premier rôle (pour que l’administrateur initial puisse entrer sans se verrouiller dehors) est une recette documentée, pas une improvisation.

Phase 4 — Déploiement

Le workflow d’intégration continue vient lui aussi d’un gabarit : authentification fédérée vers Azure (zéro secret de déploiement par app), build bundlé, gate de santé qui interroge l’app déployée avant de déclarer le déploiement réussi, tests de fumée. Il naît dormant (désactivé) tant que l’infrastructure n’existe pas. Le provisionnement Azure est un script unique avec validation préalable (« what-if ») et le second arrêt humain ; chaque ressource créée a sa contrepartie dans l’infrastructure-as-code, et une vérification hebdomadaire détecte toute dérive entre le déclaré et le réel.

Phase 5 — Activation

La naissance se termine par : l’activation de l’isolation par compagnie (la politique dormante passe à l’état actif, et la preuve comportementale — « sans contexte de compagnie, zéro ligne visible » — entre dans la batterie de tests exécutée à chaque build), la tuile dans le Hub (le portail interne), la documentation (page sur ce site, mise à jour de la carte d’architecture), et une période de dogfood avant l’annonce.

Ce que « indiscernable d’une app native » veut dire

À la fin du chemin, rien ne distingue l’app nouvelle d’une app historique : mêmes en-têtes de sécurité, même modèle d’accès par rôles et compagnies, même isolation de données prouvée par les mêmes tests, même télémétrie, même design, même processus de migration, même documentation. C’est le contrat du Golden Path — et c’est testé, pas déclaré : l’exercice de l’app fantôme est rejouable à volonté, et chaque hésitation qu’il révèle est un défaut de documentation à corriger, pas une excuse.

Pour aller plus loin

• Architecture C4 — où la nouvelle app s’insère dans la carte.
• Modèle d’accès — rôles, compagnies, délégation.
• Architecture de données — schémas par domaine et isolation RLS.
• Cycle de vie des données — ce que l’app rejoint côté gouvernance.
• Interne (dépôt) : docs/standards/GOLDEN_PATH.md v2 (la checklist maîtresse), docs/runbooks/ONBOARDING-NOUVELLE-APP.md (le pas-à-pas exécutable), docs/skills/templates/app-c-ready/ (les gabarits).