Le projet en un coup d’œil
Interfaces, collectes planifiées, messages asynchrones, base relationnelle, cache et reverse proxy doivent évoluer ensemble sans partager la même responsabilité.
PHP-FPM, Nginx, MySQL, Redis, RabbitMQ et cron disposent chacun de leur cycle, tandis que les mêmes images applicatives servent les contextes maîtrisés.
Le pipeline construit un tag intermédiaire, contrôle architecture, migrations et tests, puis le promeut sous le tag consommé par le déploiement.
Une application marketplace peut sembler classique depuis le navigateur. En exploitation, elle doit pourtant servir les pages, collecter des commandes et des offres à intervalles réguliers, distribuer des calculs lourds, conserver des fichiers, mettre en cache des données et absorber des traitements qui ne doivent jamais bloquer une requête utilisateur. Installer seulement le code PHP ne livre donc pas le produit.
Dawap a transformé Ciama en un socle Docker exploitable dans quatre contextes : local, sandbox, production et démonstration. La production répartit six responsabilités centrales entre PHP-FPM, Nginx, MySQL, Redis, RabbitMQ et un conteneur cron. Les fichiers téléversés, exports, données relationnelles et données Redis disposent de volumes distincts.
Le projet apporte surtout une chaîne de confiance. La CI construit d’abord une image PHP intermédiaire, vérifie les frontières du domaine, l’alignement des files avec les workers, les migrations et les suites applicatives, puis seulement la republie sous un tag testé. C’est cette discipline d’agence marketplace vendeurs qui transforme des connecteurs et des écrans en logiciel déployable, observable et réversible.
1. Ciama, un cockpit métier dont le run fait partie du produit
Faire cohabiter le temps réel du web, le rythme du cron et la profondeur de l’asynchrone
Ciama relie ERP, marketplaces et sites e-commerce. Certaines opérations répondent immédiatement à un utilisateur ; d’autres parcourent un historique, rafraîchissent des statistiques, exportent une recherche ou synchronisent un stock. Les exécuter dans le même cycle HTTP rendrait le temps de réponse et les erreurs difficiles à maîtriser.
L’architecture sépare donc la façade web des tâches récurrentes et des consommateurs de messages. Nginx sert les fichiers publics et transfère les requêtes dynamiques à PHP-FPM. RabbitMQ transporte les travaux asynchrones. Redis porte le cache. MySQL conserve les données structurées. Cron déclenche les collectes et maintenances selon leur cadence.
Cette séparation ne doit pas produire six versions différentes de l’application. Le service PHP web et le service cron utilisent la même image applicative de production. Les définitions de workers sont embarquées dans cette image avec Supervisor. Le code, les dépendances et les commandes restent donc cohérents entre les rôles.
Le déploiement on-premise devient ainsi une question d’assemblage contrôlé. Les paramètres de connexion et de mode changent selon l’environnement ; les responsabilités et les contrats de l’application restent reconnaissables. Le socle peut évoluer sans réinventer son exécution à chaque nouvelle fonctionnalité.
2. Durcir le socle au rythme de la complexité métier
D’octobre 2025 à septembre 2026, de l’OMS initial aux contrôles de promotion des images
La première composition production apparaît le 26 octobre 2025 avec le MVP OMS de Ciama, accompagnée de configurations sandbox. Lorsque les commandes deviennent asynchrones trois jours plus tard, les définitions de workers entrent dans l’image. La marge, les produits, les stocks et les rapports étendent ensuite progressivement le nombre de traitements.
En mars 2026, le cron obtient son propre conteneur. Son point d’entrée transforme l’environnement du conteneur en variables lisibles par les tâches, initialise la crontab et exécute les commandes Symfony avec l’utilisateur applicatif. Dans le même temps, les files sont regroupées par fonctions et les configurations sandbox, production et démonstration sont alignées.
Les 17 et 18 mars, la CI ajoute des garde-fous sur les frontières du domaine, la parité entre transports Messenger et workers, les migrations, la restauration de base et le smoke test HTTP. Fin avril, les jobs PHP sont consolidés et les définitions Supervisor suivent l’évolution des transports.
Le 8 septembre 2026, les constructions Docker-in-Docker sont ajustées au moteur de CI et l’attestation non prise en charge est désactivée explicitement. La version racontée ici est donc celle d’un socle vivant : chaque ajout métier entraîne une vérification de sa place dans l’image, les files, la planification et la chaîne de publication.
3. Avant le socle : des fonctionnalités qui dépendaient déjà d’une exploitation
Le web ne représentait qu’une partie du système réel
Le premier MVP pouvait centraliser les commandes et relier des offres, mais ces fonctions créaient immédiatement des besoins d’infrastructure. Une collecte doit être déclenchée, son travail distribué, ses échecs conservés et ses effets rendus visibles. Le code métier seul ne porte pas cette continuité.
À mesure que le produit ajoute marge, statistiques, stock, achats fournisseurs et Buy Box, le nombre de tâches longues augmente. Lancer ces opérations manuellement ou depuis une requête web produit des dépendances invisibles : une session fermée trop tôt, un processus interrompu ou une nouvelle file sans consommateur.
Le risque principal devient alors l’écart de configuration. Une classe peut publier un message vers une file déclarée dans Symfony, sans que l’environnement cible dispose du worker correspondant. Une commande peut être renommée alors que la crontab continue d’appeler l’ancien nom. Une migration peut fonctionner localement mais laisser un schéma divergent.
Le projet de socle on-premise répond à ces écarts. Il ne se limite pas à empaqueter l’application ; il relie les artefacts d’exécution et ajoute des contrôles qui échouent lorsque leurs contrats se désalignent.
4. Rendre l’installation reproductible sans prétendre uniformiser tous les hôtes
Des artefacts communs, des paramètres propres à chaque contexte
Le premier objectif était de définir les responsabilités minimales du run. Le serveur web, l’application PHP, la base, le cache, le transport de messages et la planification devaient pouvoir être déployés, redémarrés et diagnostiqués séparément.
Le deuxième objectif consistait à construire des images déterministes à partir du code et de ses dépendances verrouillées. L’image de production installe les bibliothèques Composer depuis le fichier de verrouillage, puis copie les mêmes dépendances dans l’étape finale avec les sources Symfony.
Le troisième objectif était de protéger la publication. Un artefact simplement construit porte un tag intermédiaire. Le tag consommable par le déploiement n’est créé qu’après les contrôles statiques, la préparation d’une base de test, les migrations et les suites prévues dans la chaîne.
Enfin, le socle devait conserver des limites honnêtes. Docker Compose apporte une topologie reproductible, mais pas à lui seul une sauvegarde externalisée, une haute disponibilité, une rotation de secrets ou une mise à jour sans interruption. Ces exigences restent des décisions d’exploitation par installation.
5. Décliner quatre contextes sans modifier le cœur métier
Local, sandbox, production et démonstration
L’environnement local monte directement les sources dans les conteneurs PHP et Nginx. Il fournit MySQL, Redis, RabbitMQ et des interfaces d’administration utiles au développement. Les ports et identifiants viennent de son fichier d’environnement, ce qui permet à plusieurs postes de conserver la même topologie.
La sandbox utilise des images de la branche de développement et un mode applicatif dédié. La production consomme les images de la branche principale. Toutes deux gardent les mêmes familles de services afin que la validation ne repose pas sur une architecture sans rapport avec celle qui sera exploitée.
La démonstration possède son propre mode et sa propre base. Son cron est placé derrière un profil Compose : il reste désactivé par défaut et ne démarre que sur demande. Une instance de démonstration ne lance donc pas automatiquement toutes les collectes récurrentes d’un environnement opérationnel.
Ces variantes ne sont pas décrites comme identiques. Le local ajoute des outils, la démo neutralise le cron par défaut et chaque contexte porte ses paramètres. La cohérence recherchée concerne les rôles et l’image applicative, pas une copie aveugle de toutes les options.
6. Séparer six rôles centraux dans la composition de production
Une panne ou une charge ne doit pas rendre toutes les responsabilités indistinctes
PHP-FPM exécute Symfony et monte les répertoires de téléversement et d’exports. Nginx porte la façade HTTP et lit les fichiers publics. MySQL conserve les objets métier. Redis fournit son service de données rapides. RabbitMQ transporte les messages. Cron possède son propre cycle pour lancer les commandes planifiées.
La séparation PHP-cron est particulièrement importante. Les tâches programmées utilisent la même image que le web, mais leur conteneur démarre le service cron et reste vivant indépendamment de PHP-FPM. Une évolution de cadence ne demande pas de modifier le serveur HTTP.
Une interface d’administration de base complète la composition, sans entrer dans les six rôles nécessaires à l’application. Cette distinction évite de présenter un outil d’exploitation comme une dépendance métier obligatoire.
Les services de données disposent de volumes persistants et les services HTTP dépendent du rôle applicatif pertinent. Le déploiement peut ainsi remplacer PHP, cron et Nginx sans supprimer volontairement les volumes MySQL, Redis, uploads et exports.
7. Construire l’image PHP en deux étapes
Préparer les dépendances une fois, puis assembler le runtime
La première étape part de PHP 8.5 FPM, installe les bibliothèques nécessaires aux formats, images, archives et messages AMQP, puis ajoute les extensions PHP utiles. Composer 2.8.10 est fixé pour cette phase et installe les dépendances depuis les manifestes avant la copie de toutes les sources.
L’étape finale repart d’une image PHP-FPM propre. Elle installe les extensions de runtime, Redis, cron et Supervisor, fixe le fuseau Europe/Paris, prépare les polices et les outils de génération documentaire, puis reçoit le dossier vendor produit à l’étape précédente.
Les sources Symfony sont ensuite copiées. Les répertoires de cache, logs et exécution sont créés avec les droits adaptés à l’utilisateur web. Les configurations de cron et de workers rejoignent la même image, ce qui empêche leur version de dériver de celle des commandes applicatives.
Le résultat n’est pas décrit comme minimal : l’image assume plusieurs capacités documentaires et opérationnelles. Son intérêt tient à sa reproductibilité et à la présence explicite des dépendances, pas à une promesse de taille réduite.
8. Isoler les fichiers publics dans une image Nginx non privilégiée
Servir le statique et transmettre uniquement le dynamique à PHP-FPM
L’image web part de la variante Nginx unprivileged. Elle supprime la configuration par défaut, installe le virtual host Ciama et définit un upstream vers le service PHP sur son port FPM. Après sa préparation, le processus revient à l’utilisateur nginx.
Le dossier public Symfony est copié dans l’image Nginx. Les ressources statiques courantes reçoivent une durée de cache d’un an. Les autres chemins essaient d’abord un fichier réel, puis sont réécrits vers le point d’entrée PHP.
La configuration sépare aussi le domaine principal de sa variante www par une redirection. Le service écoute dans le conteneur sur le port 8080 et se raccorde au reverse proxy externe grâce au réseau partagé préparé lors du déploiement.
Cette image reste distincte de PHP. Une modification purement publique peut produire un artefact web, tandis qu’un changement métier passe par l’image applicative et ses contrôles. Les deux responsabilités ne sont pas fusionnées dans un serveur polyvalent.
9. Distinguer artefacts remplaçables et données persistantes
Images, volumes métier et paramètres n’ont pas le même cycle de vie
Le code et les dépendances sont intégrés aux images et peuvent être remplacés par une nouvelle version. À l’inverse, MySQL monte son répertoire de données, Redis son stockage, et l’application monte les téléversements ainsi que les exports. Le remplacement d’un conteneur n’implique donc pas la suppression de ces emplacements.
Le dossier d’uploads est partagé entre PHP, cron et Nginx lorsque chacun doit écrire, produire ou servir un fichier. Les exports restent montés dans le rôle PHP qui les génère et les expose au parcours applicatif. Cette distinction limite le partage de répertoires au besoin réel.
Les paramètres d’environnement sélectionnent le mode applicatif, les connexions à la base, au transport de messages et à Redis, ainsi que l’envoi d’e-mails et l’hôte public. Le secret applicatif de production est exigé au démarrage plutôt que remplacé par une valeur par défaut.
La présence de volumes n’est pas une sauvegarde. Elle protège le cycle de remplacement des conteneurs ; la copie hors hôte, la rétention et la restauration vérifiée demandent une politique supplémentaire. Le pipeline propose une répétition de restauration, mais son déclenchement production reste planifié sous condition ou manuel.
10. Contrôler que chaque file déclarée possède un consommateur
Vingt-trois transports explicites vérifiés dans sandbox et production
La configuration Messenger définit des files pour les statistiques mensuelles, les rapports, la Buy Box, le stock d’offre, les fiches marketplace et la logistique. Chaque message est routé vers la file correspondant à sa responsabilité, tandis qu’une file d’échec Doctrine conserve les traitements qui ne peuvent pas aboutir.
L’image de production embarque soixante définitions Supervisor. Cinquante et une sont prévues en démarrage automatique ; neuf collectes Odoo restent explicitement manuelles. Cette nuance évite qu’un connecteur en attente de validation opérationnelle se réactive par simple redémarrage du service.
Un contrôle statique lit les transports disposant d’une file explicite dans la configuration Symfony, puis lit les commandes `messenger:consume` déclarées pour sandbox et production. Si l’une des vingt-trois files n’est couverte dans un environnement, le job échoue avec la liste manquante.
Ce garde-fou ne prouve pas qu’un consommateur tourne à chaque instant. Il prouve que la configuration d’exploitation sait comment le lancer. L’état runtime et le backlog doivent ensuite être supervisés sur l’installation réelle.
11. Versionner vingt tâches de production et leurs cadences
Collectes, rapports, maintenance et enrichissements restent relisibles
La crontab de production contient vingt lignes actives. Les commandes couvrent notamment commandes, offres, stocks, fulfillments, catalogue 1UP, Buy Box, reporting, synchronisation de TVA et purges de données techniques. Chaque cadence est stockée avec le code qui implémente la commande.
Au démarrage du conteneur cron, les variables reçues sont échappées dans un fichier d’environnement. Le service cron démarre ensuite, mais chaque commande Symfony est exécutée comme utilisateur www-data et en environnement de production. Les sorties vont vers les logs du conteneur.
Un contrôle spécialisé vérifie plusieurs décisions sensibles : les collectes de stock attendues doivent rester présentes, le catalogue 1UP doit passer par sa commande dédiée et neuf consommateurs Odoo ne doivent pas redémarrer automatiquement. Il vérifie également que d’anciennes variables de connexion ne reviennent pas dans le runtime ciblé.
La planification est donc traitée comme du code. Renommer une commande, changer une isolation ou activer une collecte impose de modifier sa source versionnée et de passer le contrôle correspondant, au lieu de laisser une crontab inconnue sur un serveur.
12. Promouvoir l’image PHP après contrôle plutôt que publier le premier build
Un tag intermédiaire devient le candidat testé
Sur la branche principale, le pipeline construit une image PHP de production sous un tag intermédiaire. Les tests statiques et la campagne PHP utilisent cet artefact précis. Le job de publication finale dépend explicitement de la construction et de ces deux contrôles.
Lorsque les dépendances sont satisfaites, la CI récupère l’image intermédiaire, lui attribue le tag PHP de production associé à la branche et la pousse dans le registre. Le déploiement ne consomme donc pas directement le nom réservé aux builds non validés.
Le contexte de développement suit la même logique avec ses propres tags. La démonstration construit une image dédiée puis ne la promeut qu’après la campagne PHP de production. Les artefacts restent identifiables par branche, ce qui limite les confusions entre develop et main.
La chaîne ne prétend pas signer ni attester ce que le moteur actuel ne sait pas produire. Le paramètre qui désactive les attestations automatiques non prises en charge est déclaré explicitement. Cette limitation assumée vaut mieux qu’une provenance annoncée mais absente.
13. Faire des migrations la seule voie acceptable vers le schéma attendu
Créer, migrer, valider puis vérifier qu’aucun SQL ne reste à appliquer
La campagne de test supprime et recrée sa base, synchronise la table de suivi des migrations puis applique toutes les migrations sans interaction. Elle valide ensuite le mapping Doctrine et interroge le statut pour exiger zéro nouvelle migration en attente.
Un second contrôle demande à Doctrine de produire le SQL qui séparerait encore le schéma de test du mapping. Le fichier doit rester vide. Une modification d’entité non accompagnée de sa migration ne peut donc pas être masquée par une mise à jour automatique du schéma dans le pipeline.
Une répétition de restauration complète ce parcours. Elle crée un dump, recrée la base, restaure les données puis valide le schéma et le démarrage Symfony. En production, ce job est disponible manuellement et peut être lancé par une planification munie d’une variable dédiée.
Cette répétition ne remplace pas une vraie sauvegarde de production. Elle vérifie le geste technique sur la base de test du pipeline et rend le chemin de restauration exécutable avant qu’un incident ne l’impose.
14. Reprendre l’image promue et vérifier qu’elle sert réellement une page
Le contrôle post-publication ne se contente pas de relire le tag
Après la promotion de l’image PHP, un job dédié la télécharge depuis le registre. Il prépare une base de test, rejoue les migrations, valide le schéma et demande à Symfony de décrire son environnement. Cette étape vérifie que l’artefact publié reste exécutable hors du job qui l’a construit.
Le script de smoke démarre ensuite le serveur PHP intégré sur une adresse locale et appelle la page de connexion. Il accepte une réponse HTTP comprise entre 200 et 399 seulement si le corps contient plus de dix caractères. Trente tentatives bornent l’attente de démarrage.
Le même job vérifie enfin que l’API de gestion RabbitMQ répond. Il ne simule pas toutes les collectes métier, mais couvre la présence des trois services externes nécessaires à la séquence : MySQL, Redis et RabbitMQ.
Ce smoke intervient après la publication du tag testé. Il sert donc de contrôle post-push et non de barrière préalable à la promotion. La distinction reste explicite : elle aide à comprendre à quel moment un incident serait détecté et quelle image devrait être retirée.
15. Déployer par images et reconnecter la stack à son reverse proxy
Une procédure reproductible, mais pas un rolling update
Le script production cible explicitement les conteneurs PHP, cron et Nginx de la stack. Il les arrête et les supprime s’ils existent, télécharge les images du registre puis relance la composition. Les services de données restent gérés par Compose et leurs volumes persistent sur l’hôte.
Le script crée le réseau externe s’il manque, puis y connecte Nginx et les interfaces d’exploitation concernées. Il redémarre le reverse proxy partagé et ouvre enfin un shell dans le conteneur PHP pour les opérations manuelles qui accompagnent le déploiement.
Les opérations de connexion réseau sont idempotentes : une relation déjà présente ne bloque pas la suite. Les arrêts et suppressions tolèrent eux aussi l’absence d’un ancien conteneur. Le même principe est repris dans le contexte de démonstration.
Cette procédure remplace les conteneurs applicatifs ; elle n’organise pas une bascule progressive entre deux versions. Une exigence de zéro interruption demanderait une orchestration supplémentaire, des healthchecks de service et une stratégie de routage adaptée.
16. Choisir la simplicité opérable plutôt qu’une abstraction prématurée
Compose, images dédiées et contrôles lisibles
Docker Compose a été retenu comme niveau d’orchestration du socle actuel. Les services, volumes, dépendances et paramètres tiennent dans une composition relisible. Ce choix correspond à une installation maîtrisée sur un nombre limité d’hôtes, sans introduire une plateforme de cluster dont le besoin n’est pas démontré.
Le web et cron partagent l’image PHP afin de garder les mêmes commandes et dépendances. Nginx conserve une image séparée, car ses fichiers publics et son cycle HTTP ne demandent pas le runtime PHP. Cette séparation équilibre cohérence et spécialisation.
Les cadences restent dans une crontab plutôt que dans une interface distante. Les travailleurs sont décrits par Supervisor. Ces mécanismes classiques rendent les opérations visibles aux équipes capables d’administrer l’hôte et peuvent être contrôlés par de petits scripts versionnés.
En contrepartie, le socle exige une discipline sur les fichiers d’infrastructure. Ajouter un message, une commande ou un paramètre ne se termine pas dans le code Symfony : les configurations d’exécution et leurs contrôles doivent évoluer dans le même changement.
17. Préparer le diagnostic et le retour à une image stable
Migrations, queues, workers, cron et rollback disposent d’un parcours
Le guide d’incident classe les pannes selon cinq familles : base et migrations, file RabbitMQ bloquée, consommateur absent, écart de crontab et test instable. Pour chacune, il donne une commande de diagnostic et le contrôle à renforcer après correction.
Le rollback applicatif repose sur les images. L’opérateur identifie le tag stable précédent, le redéploie puis relance les smoke tests. Une analyse de cause doit ensuite relier l’incident, son impact, sa détection, le correctif et la prévention ajoutée.
Des objectifs de service documentent zéro dérive SQL, au moins un consommateur par file critique et des plafonds de deux cents messages prêts ou en cours sur quatre queues logistiques. Ces valeurs constituent des cibles d’exploitation ; elles ne prouvent pas à elles seules qu’une instance les respecte actuellement.
Cette dernière distinction est importante. Un runbook et un seuil créent une capacité de réponse. Seule la mesure continue sur l’installation démontre le niveau réel de service. Le socle prépare la pratique sans transformer la documentation en résultat.
18. Passer d’un serveur configuré à la main à un artefact vérifiable
Un avant-après observable dans la chaîne de livraison
Avant l’industrialisation, une fonctionnalité pouvait dépendre d’une commande connue d’une personne, d’un worker ajouté sur un seul environnement ou d’un schéma ajusté localement. Le logiciel et sa manière de tourner risquaient de diverger sans signal immédiat.
Après la livraison, les quatre contextes possèdent leurs définitions, la production répartit ses six rôles et les tâches sont versionnées. Les vingt-trois files explicites peuvent être comparées automatiquement aux configurations de workers de sandbox et production.
L’image PHP promue est exactement celle qui a subi la préparation de base, les migrations et les tests du pipeline. Le smoke post-push reprend ensuite ce tag depuis le registre. Une anomalie peut être rattachée à un artefact, une étape et une configuration plutôt qu’à un serveur indéterminé.
Pour les équipes marketplace, le gain se traduit par une fondation capable d’accueillir de nouvelles collectes et de nouveaux rapports sans cacher leur coût opérationnel. Chaque capacité doit déclarer comment elle se planifie, se distribue, se teste et se récupère après échec.
19. Définir ce qu’il reste à adapter avant une nouvelle installation
Le socle actuel est concret, pas universel
Les compositions portent des domaines, modes et conventions propres aux environnements Ciama actuels. Une nouvelle installation demande de fournir ses paramètres, d’externaliser tous ses secrets, de choisir ses accès d’administration et de vérifier la politique réseau de l’hôte.
Les volumes locaux protègent les données du remplacement d’un conteneur, mais ne fournissent ni réplication ni sauvegarde hors site. La rétention, le chiffrement, les tests de restauration et le plan de continuité doivent être définis selon les objectifs du client.
Le script de déploiement arrête les conteneurs applicatifs avant de les recréer. Il ne promet donc ni haute disponibilité ni déploiement sans interruption. Ces capacités nécessiteraient plusieurs réplicas, des contrôles de santé, une bascule et une stratégie de migration compatible.
Enfin, certains contrôles runtime avancés présents dans la CI sont désactivés, tandis que la répétition de restauration production reste manuelle ou conditionnelle. La fiche ne les présente pas comme une garantie active. Elle distingue les barrières obligatoires, les contrôles post-push et les exercices disponibles.
20. Donner une infrastructure aux fonctions marketplace qui tournent en arrière-plan
Exports, supervision et connecteurs reposent sur le même socle
Le projet d’export asynchrone des commandes illustre directement la séparation web-message : l’interface formule la demande, une file transporte le travail et un worker produit le fichier sans garder la requête ouverte.
La supervision des traitements métier rend ensuite ces exécutions lisibles avec leurs étapes et leurs résultats. Elle apporte le point de vue opérationnel qui complète les définitions de cron et de workers.
Le hub des connecteurs marketplace montre enfin pourquoi le socle doit isoler les fonctions par compte et par fournisseur. Activer une collecte métier suppose que son transport, son consommateur et sa cadence existent dans le runtime.
Ces briques prolongent l’accompagnement Agence marketplace vendeurs : connecter le canal, construire le parcours métier, puis livrer les conditions techniques qui permettent à ce parcours de tenir après la mise en ligne.
21. Conclusion
Le déploiement fait partie de la preuve, pas de l’après-projet
Ciama ne devient pas on-premise parce que ses sources sont copiées sur un serveur. Il le devient lorsque l’application web, les données, les messages, les planifications, les volumes et les images possèdent une topologie et un chemin de mise à jour explicites.
La singularité de cette livraison tient à ses contrôles croisés : vingt-trois files comparées aux workers, vingt tâches de production versionnées, des migrations rejouées sur une base neuve et une image intermédiaire promue seulement après la chaîne prévue.
C’est ce niveau de continuité que Dawap apporte dans son offre Agence marketplace vendeurs : ne pas séparer la fonctionnalité de son exploitation, documenter les limites actuelles et faire évoluer ensemble le métier, l’artefact et le run.
