Votre code dans Git.
Un processus suivi jusqu’au service.
Une configuration versionnée décrit l’application, ses environnements, ses services et ses ressources. Chaque livraison suit le commit client et les contrôles associés.
Quatre niveaux, un graphe de dépendances
Les niveaux désignent des responsabilités réutilisables. On choisit généralement une application N3, puis on examine les capacités qu’elle consomme. Un projet de code client peut aussi partir directement d’un N1.
Les quatre niveaux ne sont pas une chaîne obligatoire. Un N3 utilise directement des N1 et éventuellement des N2 ; un N2 peut utiliser un N1, puis les ressources N0. FreshRSS et DokuWiki ne nécessitent pas de serveur SQL N2. Le SSO / OIDC raccorde un fournisseur existant.
Une configuration connue suit une livraison déterministe
Le parcours normal n’appelle aucun modèle de langage. Le produit exécute les recettes publiées avec leurs paramètres et leurs dépendances. Les skills servent à analyser et faire évoluer les capacités ; ils ne sont pas interprétés par un modèle à chaque push.
- 1 projet, 1 commitLe code complet, les dépendances verrouillées et
paas.tomlarrivent sur la branche de livraison du dépôt lié à l’application. - Résoudre la compositionLa recette, sa version et ses paramètres sont validés. La plateforme prépare les capacités N1/N2 et ressources N0 nécessaires.
- Construire et contrôlerCompilation, tests, scan de vulnérabilités, inventaire logiciel, signature et admission relient le résultat aux sources exactes.
- LivrerLes accès autorisés et le compte initial sont préparés. Le suivi conserve les étapes, leurs états et le résultat de livraison.
- Vérifier le serviceLe contenu réellement servi et une opération métier confirment le résultat, au-delà d’un build terminé.
- Conserver la traceLe commit, les erreurs éventuelles et les résultats restent associés au projet. Une reprise utilise ce suivi durable.
Une fiche de catalogue seule ne rend pas une capacité exécutable. Le résolveur, la recette et le fournisseur doivent effectivement prendre en charge l’opération.
Une application, plusieurs capacités partagées
N3 WordPress → N1 PHP et persistance + N2 MySQL → ressources N0. L’application et sa base utilisent les conteneurs, volumes et allocations de stockage nécessaires à leur responsabilité. Le volume et le bloc décrivent deux couches de la même allocation : ils ne doublent pas la quantité de stockage comptée.
Dans le scénario qualifié, la mise à jour de WordPress conserve le compte, l’article et le média, puis une nouvelle écriture vérifie l’usage après livraison. Cette mise à jour de l’application ne qualifie pas une mise à jour du moteur MySQL. Sauvegarde et restauration restent des opérations distinctes, avec leurs propres états.
FreshRSS suit un autre graphe : PHP, persistance, composition et tâche périodique utilisent SQLite embarqué, sans serveur SQL N2. Les besoins du projet déterminent les dépendances ; le nombre d’étages n’est pas imposé.
Mettre à jour dans le même projet
Le nouveau code et la configuration compatible passent par le même parcours. Dans les scénarios vérifiés, les comptes, identités, réservations de services et données persistent. Une nouvelle écriture métier après la livraison complète la vérification.
Trois versions se distinguent : le logiciel applicatif, la recette publiée et le contrat d’inventaire de la capacité. Un contrat d’inventaire 1.0.0 ne signifie ni logiciel 1.0.0 ni recette 1.0.0. Le commit client identifie aussi le code effectivement construit.
Les dernières qualifications comprennent des révisions compatibles du code client à version amont constante, notamment Metabase, Plausible, Nextcloud et OpenCart. Elles prouvent la conservation des données et un nouvel usage dans le même projet, sans appel de modèle sur l’upgrade. Elles ne prouvent pas une migration vers une nouvelle version du logiciel ; les appels de la création initiale restent comptabilisés.
Changer de version d’application ne qualifie pas automatiquement une migration majeure du runtime ou du moteur de base. Consultez les couples de versions et les opérations dans la fiche du module.
Sauvegarde et restauration sont deux opérations distinctes. Toutes les restaurations du présent relevé restent non vérifiées. Des exports SQL et fichiers séparés ne prouvent pas non plus un snapshot transactionnel conjoint. Un retour du code à une version antérieure ne suffit pas à rendre les données compatibles avec cette version.
Quand une configuration manque ou qu’une étape échoue
Une configuration absente ou invalide, un refus récupérable avant construction ou un échec terminal peut ouvrir la réparation. Une construction ou une période d’observation encore active reste une attente.
- Le diagnostic transmet au modèle privé des métadonnées filtrées, sans secrets ni sources métier ni journaux complets du client.
- La proposition peut modifier uniquement
paas.toml. Elle ne corrige pas directement votre code métier. - La correction devient un commit sur une branche du même dépôt. Elle passe les validations et la CI, puis une demande de fusion (PR).
- L’intégration en fast-forward respecte le HEAD client. Un push concurrent qui diverge empêche la fusion de la correction obsolète.
- Le résultat intégré reprend les contrôles de livraison et la vérification du service.
Un échec d’usage reste un échec après « ready »
Une page d’accueil et un état technique prêt ne suffisent pas. Si la session disparaît, si un éditeur ne charge pas les données ou si une fonction métier échoue, le contrôle refusé est enregistré avec sa preuve privée et le commit servi. La réparation ou une configuration revue reprend dans le même incident. CryptPad et OpenCart ont suivi ce chemin ; leur création n’est qualifiée qu’après vérification de l’usage corrigé.
Reprendre après le budget automatique
Le budget de découverte et de réparation est fixé à trois appels privés pour le même incident. Publier une capacité, corriger la plateforme ou pousser une maintenance pendant une installation inachevée conserve le suivi et le compteur. Après épuisement, un intervenant autorisé peut soumettre une configuration revue, avec la preuve de la correction et les droits requis. Elle passe encore par la branche, la CI, la PR et la publication ; la reprise ne demande pas de nouvel appel au modèle.
Les campagnes historiques gardent leurs refus et leurs totaux : Drupal et PrestaShop comptent chacun six appels sur deux lignées de création ; Discourse en compte sept sur ses sources successives. Immich conserve explicitement un écart de quatre appels historiques au total de trois annoncé. La continuité du compteur a été corrigée pour les futures installations inachevées ; cela ne réécrit pas les campagnes précédentes.
Si une capacité manque, l’incident reste visible avec son diagnostic. Le modèle privé peut l’identifier ; le développement et la publication de la capacité passent par un travail autorisé et testé. Un défaut des dépendances applicatives peut exiger un vrai push de maintenance du code client, distinct du patch de configuration. Suivre le traitement d’un nouveau cas →
Reprendre une installation sans écraser son contenu
Une interruption n’autorise pas à relancer aveuglément l’installateur. La recette vérifie d’abord l’état de l’instance et les données déjà présentes. Les conditions de reprise dépendent de l’application.
BookStack : reprendre la même initialisation
La recette compile sa configuration pour éviter qu’une variable d’environnement masque son fichier .env. Une création interrompue peut reprendre sans réinstallation si la configuration correspond à la même instance et si seules les données de l’installateur sont présentes.
Le premier incident BookStack, sur une autre instance, conserve trois appels privés et sa reprise après correctif. Il ne compte pas comme création qualifiée. La création neuve vérifiée de BookStack 26.05.5 et sa mise à jour compatible utilisent zéro appel de modèle, avec contenus et accès contrôlés.
NodeBB : vérifier l’absence de contenu avant une relance
Pour NodeBB 4.16.0, la relance de l’installateur exige une absence de contenu métier prouvée. Les assets sont régénérés à chaque démarrage dans une zone privée prévue par la recette ; ils ne constituent pas des documents à restaurer. Les exports MongoDB excluent les sessions, et les exports de fichiers excluent ces sorties régénérables. Leur réussite ne qualifie pas une restauration.
Ce que signifie « vérifié »
Le catalogue publie l’état de chaque opération, ses versions, son usage et ses limites. Une création vérifiée ne qualifie pas toutes les sauvegardes, restaurations, migrations ou personnalisations du même logiciel.
Le relevé décrit des campagnes d’installation et de mise à jour datées. Il ne constitue pas un nouveau contrôle en direct de chaque application, une certification indépendante ou une annonce de disponibilité commerciale générale.
Les configurations historiques valides sans bloc [n3] conservent leur parcours. Les monorepos arbitraires, miroirs externes, migrations majeures, restaurations et toutes les courses entre événements ne sont pas couverts par ces scénarios.