Quand un monolithe Symfony reste le meilleur choix

Un projet Symfony commence parfois à douter de son architecture au premier ralentissement : compilation plus longue, livraison qui touche plusieurs dossiers, table devenue centrale. Le mot « microservices » apparaît alors comme une solution globale. Le risque est de déplacer le problème dans le réseau, les files de messages et l’exploitation avant d’avoir identifié ce qui freine réellement l’équipe.

Un monolithe n’est pourtant ni une étape honteuse ni l’absence d’architecture. C’est une unité de déploiement qui peut contenir des modules distincts, des règles métier bien isolées et plusieurs traitements asynchrones. Lorsque les mêmes personnes font évoluer un domaine fortement transactionnel, cette unité réduit les coordinations et rend les changements plus simples à tester.

Le vrai enjeu est d’obtenir cette simplicité sans laisser le code devenir une masse indifférenciée. Une architecture web sur mesure doit préserver des frontières internes, une base maîtrisée, des déploiements fiables et une lecture claire des responsabilités. Sinon, le confort initial se transforme progressivement en dépendances circulaires et en livraisons anxiogènes.

Cet arbitrage se décide sur des faits : topologie d’équipe, besoin d’autonomie, cohérence transactionnelle, profils de charge, fréquence de changement et capacité d’exploitation. Le monolithe reste le meilleur choix tant qu’il diminue le coût total du produit et que ses limites peuvent encore être déplacées sans réécriture massive.

Plan d’action : rendre le maintien d’un monolithe Symfony vérifiable

Point de départ pour une application métier portée par une équipe avec des règles fortement transactionnelles : Un monolithe reste un bon choix lorsque les transactions, les équipes et le rythme de livraison gagnent à partager un déploiement. Le vrai risque vient d’un code sans frontières, pas du nombre de processus. L’équipe commence donc par l’hypothèse la plus coûteuse si elle est fausse, puis garde une décision réversible tant que les preuves restent incomplètes.

Confronter deux cas concrets avant de généraliser

Lecture contradictoire pour un module à cadence distincte qui surcharge chaque déploiement global : Cas concret A — une application métier portée par une équipe avec des règles fortement transactionnelles. Le protocole nomme l’entrée, le résultat, la source de vérité et la personne autorisée à trancher. La trace doit permettre à un second lecteur d’expliquer l’écart sans assister à la réunion initiale.

Contrôle terrain pour le maintien d’un monolithe Symfony : Cas concret B — un module à cadence distincte qui surcharge chaque déploiement global. Le test provoque aussi le refus, l’indisponibilité ou la donnée limite. Il distingue un défaut local d’une faiblesse du modèle et chiffre le travail déplacé vers le support.

Limite de run pour une application métier portée par une équipe avec des règles fortement transactionnelles : Une règle locale possible consiste à conserver le monolithe tant que les modules restent testables et que quatre livraisons sur cinq n’exigent pas de coordination externe. Ce seuil n’est pas une norme universelle : il doit être validé selon le coût d’erreur, les volumes, la criticité et la capacité de reprise.

Relier le contrat technique à la responsabilité métier

Preuve attendue pour un module à cadence distincte qui surcharge chaque déploiement global : Les namespaces, services et modules protègent les dépendances ; les tests de contrat, migrations, cache, queue, monitoring et rollback rendent chaque évolution observable. Cette chaîne rend les décisions auditables sans prétendre empêcher tout incident.

Décision d’architecture pour le maintien d’un monolithe Symfony : Le contrôle contradictoire récupère l’entrée, la sortie, le contrat, l’owner, les dépendances et la journalisation. Il provoque ensuite timeout ou rejet, compare le résultat au seuil et exécute le rollback depuis le runbook avec les mêmes droits qu’en production.

Responsabilité produit pour une application métier portée par une équipe avec des règles fortement transactionnelles : Contre-intuitivement, Investir dans un monolithe modulaire peut préparer une future extraction mieux qu’un découpage réseau précipité. Le coût complet réunit développement, recette, support, exploitation et réconciliation métier ; déplacer une tâche hors du sprint ne la fait pas disparaître.

Décider avec une séquence courte et opposable

1. Scénario dégradé pour un module à cadence distincte qui surcharge chaque déploiement global : Nommer l’hypothèse prioritaire, l’owner et la source de vérité avant toute extension.
2. Arbitrage de coût pour le maintien d’un monolithe Symfony : Rejouer les deux cas concrets avec les mêmes données, droits et métriques.
3. Revue de recette pour une application métier portée par une équipe avec des règles fortement transactionnelles : Comparer le résultat au seuil local et chiffrer le coût du contournement dans le run.
4. Condition d’arrêt pour un module à cadence distincte qui surcharge chaque déploiement global : Consigner le maintien, une modularisation ou l’extraction d’une seule capacité, sa date de revue et la preuve attendue au jalon suivant.

Pour qui cette méthode est utile

Prochain jalon pour le maintien d’un monolithe Symfony : Cette démarche s’adresse d’abord aux CTO, architectes et équipes Symfony qui évaluent une distribution de leur application. Elle est utile lorsque plusieurs équipes interprètent une même décision, que la reprise dépend d’une personne ou que le coût apparaît après la livraison.

Cas irréversible pour une application métier portée par une équipe avec des règles fortement transactionnelles : Elle reste proportionnée : un changement réversible et couvert par des tests ne justifie pas un comité lourd. En revanche, argent, droits, données, engagement client et bascule exigent une preuve et une responsabilité nominative.

Erreurs fréquentes à éliminer

Frontière technique pour un module à cadence distincte qui surcharge chaque déploiement global : La première erreur consiste à attribuer au monolithe les lenteurs causées par l’absence de tests et d’ownership. La seconde est de suivre un indicateur sans action associée. La troisième valide le cas nominal sans provoquer l’échec, le rejeu et le retour arrière.

• Signal d’alerte pour le maintien d’un monolithe Symfony : Refuser une validation sans source, responsable et preuve consultable par une autre personne.
• Trace de reprise pour une application métier portée par une équipe avec des règles fortement transactionnelles : Différer l’extension si le seuil change après le test ou si le coût de run reste inconnu.
• Choix de périmètre pour un module à cadence distincte qui surcharge chaque déploiement global : Conserver date, verdict et limite acceptée afin que le prochain lot ne rouvre pas le même risque.

Distinguer monolithe et code sans structure

Le terme décrit d’abord un mode de livraison : une application est construite, testée et déployée comme un ensemble. Il ne dit rien, à lui seul, sur l’organisation du code. Un monolithe peut posséder des modules propres, des ports, des cas d’usage et des tests ciblés. À l’inverse, plusieurs services peuvent partager la même base et le même modèle jusqu’à former un monolithe distribué.

La distinction change la conversation. Le problème n’est pas qu’un exécutable Symfony contienne commandes, facturation et catalogue. Il apparaît si n’importe quelle classe peut modifier n’importe quelle donnée, si les règles sont dupliquées et si une évolution locale exige de comprendre tout le système.

Un monolithe modulaire conserve une seule unité d’exploitation, mais impose des frontières de code. Chaque module possède son vocabulaire et son point d’entrée. Les échanges passent par des interfaces, des commandes ou des événements internes connus. La base peut rester commune tout en limitant les tables que chaque module manipule directement.

Reconnaître les situations favorables

Le premier signal est organisationnel : une ou deux équipes travaillent sur le même produit et ont besoin de livrer des fonctionnalités transverses. Découper trop tôt oblige ces personnes à maintenir plusieurs dépôts, pipelines, environnements et contrats sans obtenir une autonomie réelle.

Le deuxième est métier : les opérations modifient plusieurs concepts qui doivent rester cohérents immédiatement. Valider une commande peut réserver un stock, enregistrer un prix négocié et créer un engagement. Une transaction locale offre alors une garantie compréhensible. La remplacer par plusieurs échanges réseau introduit des états intermédiaires, des compensations et des reprises.

Le troisième est l’incertitude. Lorsque les frontières du domaine changent encore chaque mois, une séparation physique les fige au mauvais endroit. Déplacer une classe ou un namespace reste peu coûteux ; déplacer une donnée et un contrat entre services en production demande une migration, une compatibilité temporaire et de l’observabilité.

• Les équipes livrent majoritairement le même calendrier produit.
• Les opérations critiques bénéficient de transactions locales.
• La charge peut être absorbée en ajoutant des instances identiques.
• Les frontières métier ne sont pas encore suffisamment stables.
• Le coût d’exploitation de services supplémentaires dépasserait le gain d’autonomie.

Comparer les coûts complets

Une comparaison honnête ne s’arrête pas au temps de développement. Le monolithe paie un pipeline plus large, une base partagée et un risque de couplage interne. Les microservices paient la découverte réseau, l’authentification interservices, la compatibilité des contrats, la corrélation, les retries, les déploiements multiples et les incidents partiels.

Le coût dominant dépend de l’organisation. Si chaque équipe attend une autre équipe pour modifier une classe commune, la séparation peut créer de la valeur. Si les mêmes quatre personnes possèdent tous les services, elles changent surtout de dépôt et ajoutent du travail de plateforme.

Contre-intuitivement, une application unique peut offrir une meilleure capacité d’évolution qu’une architecture distribuée. Ses modules peuvent être déplacés rapidement tant que les dépendances sont contrôlées. La distribution devient utile lorsque l’autonomie gagnée vaut réellement le prix des contrats réseau et de l’exploitation séparée.

Construire de vraies frontières internes

La découpe suit des capacités métier : Catalogue, Offre, Commande, Facturation ou Support. Elle ne suit pas uniquement les couches techniques Entity, Repository et Service. Dans chaque module, on retrouve les objets métier, cas d’usage et adaptateurs qui lui appartiennent. Le nom du répertoire doit permettre à une personne du métier de reconnaître la responsabilité.

Symfony recommande de ne pas créer de bundles pour organiser la logique propre à une application ; les namespaces PHP suffisent. Les bonnes pratiques officielles du framework fournissent un point de départ, puis le projet peut structurer son répertoire métier selon ses besoins sans transformer chaque module en paquet réutilisable artificiel.

Une frontière utile a une surface étroite. Le module Commande expose par exemple PasserCommande, AnnulerCommande et quelques lectures. Il ne donne pas accès à son EntityManager ni à tous ses repositories. Le reste de l’application dépend d’intentions stables, pas de la forme actuelle des tables.

Rendre les dépendances vérifiables

Les conventions écrites ne suffisent pas. L’analyse statique ou des tests d’architecture doivent interdire les dépendances non prévues : le Catalogue ne connaît pas la Facturation ; l’infrastructure dépend des interfaces applicatives ; le domaine n’importe ni contrôleur ni classe Doctrine spécifique quand cette indépendance apporte une valeur réelle.

Le conteneur Symfony facilite l’injection par interface et garde les services privés par défaut. Cette mécanique permet de sélectionner un adaptateur sans rendre le domaine conscient du framework. La documentation du conteneur de services rappelle aussi l’intérêt d’autowiring, d’autoconfiguration et de dépendances explicites par constructeur.

Il faut néanmoins surveiller l’interface de façade qui grossit jusqu’à exposer toutes les possibilités d’un module. Une dépendance saine représente le besoin du consommateur. Elle peut être remplacée en test et son nom exprime une action ou une information, pas un accès générique aux données.

Profiter des transactions locales

Le monolithe garde un avantage fort lorsqu’une règle doit mettre à jour plusieurs agrégats sans état intermédiaire observable. Doctrine regroupe les écritures au flush() et permet de délimiter explicitement une transaction lorsque plusieurs opérations doivent réussir ensemble. Cette simplicité réduit le nombre de scénarios de compensation.

Elle ne dispense pas de traiter la concurrence. Une transaction HTTP ne peut pas couvrir le temps pendant lequel un utilisateur lit puis modifie un dossier. Un champ de version et le verrouillage optimiste permettent de détecter qu’un autre acteur a changé l’état entre-temps. La documentation Doctrine sur les transactions et la concurrence détaille ces limites.

Une transaction ne doit pas englober un appel réseau lent. L’application valide son invariant local, enregistre l’intention d’effet externe et déclenche l’envoi après validation. Un outbox ou un message persistant évite le cas où la base est engagée mais la publication disparaît.

Utiliser l’asynchrone sans distribuer le système

Une application Symfony unique peut déléguer les tâches longues à Messenger : génération de document, synchronisation ERP, envoi d’e-mail ou recalcul. Le code reste dans le même dépôt, tandis que des workers séparés absorbent la charge et peuvent être dimensionnés indépendamment.

Cette souplesse ne transforme pas chaque action en événement. Une commande synchrone reste préférable quand l’utilisateur attend immédiatement un résultat et que la cohérence locale est essentielle. L’asynchrone se justifie par la durée, la résilience ou le découplage temporel, pas pour donner une apparence distribuée à l’architecture.

Chaque message doit posséder une responsabilité, un identifiant de corrélation et une stratégie de retry. Le handler doit supporter une nouvelle livraison sans doubler l’effet ou détecter explicitement le traitement déjà effectué. La file d’échec, les délais et l’âge du plus ancien message appartiennent au tableau de bord du produit.

Aligner architecture et organisation

Une frontière technique n’accorde pas automatiquement de l’autonomie. Si toutes les décisions passent par le même product owner, la même base et la même équipe d’exploitation, séparer les déploiements ajoute des coordinations sans supprimer la dépendance principale.

Le monolithe fonctionne bien quand l’équipe peut posséder le parcours de bout en bout. Des propriétaires de modules peuvent relire les changements et maintenir leurs règles, tout en conservant un pipeline commun. Les revues transverses portent sur les contrats internes et les données partagées.

À mesure que l’organisation grandit, les files d’attente de revue, conflits de priorité et collisions de déploiement deviennent mesurables. Ce sont de meilleurs signaux de séparation que le nombre de classes. Une équipe durablement bloquée par le calendrier d’une autre peut justifier une unité de livraison distincte.

Déployer souvent sans multiplier les services

Un monolithe sain doit être banal à livrer. Le pipeline exécute les tests ciblés puis la suite critique, construit un artefact immuable, vérifie les migrations et déploie progressivement. La taille du dépôt n’excuse ni les interventions manuelles ni les fenêtres de nuit systématiques.

Les migrations de base suivent une séquence compatible : ajouter avant d’utiliser, migrer les données, basculer le code, puis supprimer plus tard. Cette discipline autorise le retour à la version précédente même lorsque deux versions de l’application cohabitent quelques minutes.

Des feature flags peuvent dissocier livraison technique et ouverture fonctionnelle. Ils doivent avoir un propriétaire et une date de retrait ; sinon ils deviennent des branches permanentes qui multiplient les chemins à tester. Le rollback, le repli fonctionnel et la restauration de données ne sont pas la même opération et doivent être préparés séparément.

Mettre à l’échelle avec méthode

Beaucoup d’applications peuvent d’abord être répliquées horizontalement derrière un répartiteur. Les sessions sont externalisées, les fichiers stockés hors du conteneur et les workers dimensionnés selon leurs files. Cette étape conserve une architecture simple et couvre souvent largement le besoin.

Le profilage doit isoler la contrainte : requête SQL, sérialisation, calcul CPU, appel externe ou contention. Extraire un service ne rend pas une mauvaise requête plus rapide. Une projection de lecture, un cache ciblé ou un traitement asynchrone apporte fréquemment un gain plus direct.

Une charge très dissymétrique peut toutefois justifier une séparation. Si la génération vidéo consomme des ressources sans rapport avec les requêtes métier, un processus ou service spécialisé se dimensionne différemment. L’extraction répond alors à une mesure stable, pas à une crainte abstraite de croissance.

Maîtriser sécurité et exploitation

Une application unique réduit le nombre de surfaces réseau, de secrets interservices et de politiques à synchroniser. Une identité entre dans le système, les voters appliquent les droits fins et les journaux partagent le même contexte. Cet avantage disparaît si les modules contournent l’autorisation ou lisent directement les tables des autres.

La panne reste globale seulement si aucune isolation n’est prévue. Les timeouts sur dépendances externes, les files séparées, les limites de concurrence et les circuits de repli empêchent une fonction secondaire de saturer tout le produit. Les endpoints de santé distinguent disponibilité du processus et capacité réelle à servir les parcours critiques.

L’observabilité doit suivre les cas d’usage : temps de passage de commande, taux d’échec d’un import, profondeur de file et erreurs par module. Un seul déploiement ne signifie pas un seul indicateur agrégé. Les dimensions fonctionnelles permettent de localiser la dégradation avant de discuter d’une extraction.

Savoir quand extraire un service

L’extraction devient défendable lorsqu’une capacité possède des données clairement détenues, un rythme de changement distinct et un besoin d’exploitation différent. Une équipe doit pouvoir en assumer le contrat, les alertes, les déploiements et les incidents. Il faut réunir plusieurs de ces signaux, pas un seul.

Un autre motif est la contrainte technique irréconciliable : langage spécialisé, isolement réglementaire, charge matérielle ou disponibilité différente. La séparation protège alors le reste du produit. Elle doit préciser ce qui se passe lorsque le nouveau service est lent, indisponible ou renvoie une réponse ambiguë.

En revanche, une table volumineuse, un dossier de code encombré ou un désaccord d’équipe se corrigent d’abord localement. Distribuer une frontière confuse la rend plus coûteuse à déplacer. Le module interne sert de période d’essai : s’il conserve son autonomie pendant plusieurs versions, il devient un bon candidat.

Préparer une extraction réversible

La première étape crée une façade interne et interdit les nouvelles lectures directes de données. Le module publie des résultats stables et reçoit des commandes explicites. Les tests de contrat fixent les entrées, les sorties, les erreurs et les règles d’autorisation.

Ensuite, les données sont attribuées. Une réplication temporaire ou un outbox peut alimenter le futur service, tandis que le monolithe reste source de vérité. L’équipe compare les résultats et mesure la latence avant de déplacer les écritures. Un identifiant de corrélation relie les deux côtés.

Enfin, une petite part du trafic est basculée avec un seuil d’arrêt et un rollback documenté. La dépendance réseau reçoit timeout, retry borné et repli. L’ancienne implémentation n’est retirée qu’après une période d’exploitation nominale et la fermeture de la synchronisation temporaire.

Décider sur trois cas concrets

Un portail B2B relié à un ERP

Cas concret. Le portail gère comptes, tarifs négociés, commandes et documents. La majorité des parcours partagent les mêmes règles et l’équipe compte six personnes. Un monolithe Symfony modulaire garde les transactions et accélère les évolutions transverses ; les échanges ERP partent en asynchrone avec reprise.

La séparation pertinente n’est pas forcément métier : les imports lourds peuvent être exécutés par des workers dédiés sans quitter l’application. Le diagnostic dépend de l’âge de file, du temps de traitement et de l’impact sur les requêtes interactives.

Une plateforme avec un moteur de calcul spécialisé

Autre cas concret. Le produit web orchestre des dossiers, tandis qu’un calcul scientifique consomme beaucoup de CPU et évolue avec une équipe distincte. Le moteur possède une entrée et une sortie stables, un dimensionnement spécifique et peut accepter un traitement différé. Une séparation devient cohérente.

Le monolithe conserve l’état du dossier et soumet une demande idempotente. Il traite succès, échec et expiration sans supposer une réponse immédiate. Le service de calcul ne partage pas les tables applicatives ; son contrat est testé des deux côtés.

Un SaaS encore en recherche de son modèle

Les rôles, offres et parcours changent toutes les deux semaines. Une découpe en services figerait des hypothèses fragiles et multiplierait les migrations coordonnées. Un monolithe bien instrumenté permet d’apprendre, renommer et déplacer les frontières rapidement.

L’équipe consigne néanmoins les dépendances et mesure la croissance de chaque module. Lorsque les usages et responsabilités se stabilisent, elle pourra extraire une capacité sur preuve, sans recommencer le produit.

Éviter les erreurs de monolithe

La première erreur est la base en libre-service. Toute classe peut joindre toutes les tables, ce qui transforme chaque schéma en contrat public interne. Les repositories et façades de module limitent ces accès sans exiger plusieurs bases dès le départ.

La deuxième est le répertoire Service qui reçoit tout ce qui n’a pas trouvé de place. Les noms deviennent génériques, les responsabilités s’accumulent et les dépendances circulaires apparaissent. Organiser par capacité, puis nommer les cas d’usage par verbe, rend les changements plus localisables.

La troisième est le grand nettoyage préalable à chaque fonctionnalité. Une architecture durable s’améliore par tranches : renforcer la frontière touchée, ajouter le test manquant, supprimer un accès direct. Attendre une refonte globale laisse la dette grandir et augmente le risque de l’opération future.

Enfin, présenter le monolithe comme un choix définitif empêche de préparer les sorties. Les contrats internes, messages idempotents et propriétaires de données gardent l’option d’extraction ouverte. Cette option vaut même si elle n’est jamais exercée.

Mesurer la santé de l’architecture

Le temps entre une demande validée et sa mise en production révèle la fluidité réelle. Il se complète par le taux de changements qui touchent plusieurs modules, la durée des tests, les incidents par capacité et le délai de diagnostic. Ces mesures montrent si l’unité de déploiement reste un avantage.

Le graphe de dépendances apporte une preuve technique : cycles, accès transverses à la base, classes centrales et évolutions des interfaces. Une hausse continue signale que les frontières internes perdent leur force. Le remède peut être un refactor local avant toute distribution.

Les indicateurs organisationnels comptent autant : temps d’attente de revue, conflits de calendrier et fréquence des livraisons coordonnées. Si un module et son équipe restent autonomes mais bloqués par le pipeline global, une extraction peut améliorer le flux. Si les changements traversent naturellement les mêmes capacités, le monolithe continue de servir le produit.

Plan d’action : renforcer le monolithe en six semaines

Semaines 1 et 2 : cartographier sans réorganiser

L’équipe liste les capacités métier, les tables modifiées, les cas d’usage critiques et les propriétaires actuels. Elle extrait le graphe de dépendances, repère les cycles et relie les incidents récents à un module. Trois parcours représentatifs servent de fil rouge.

Elle fixe des seuils simples : aucun nouvel accès direct aux tables d’un autre module, aucune dépendance du domaine vers HTTP et un propriétaire pour chaque interface partagée. Ces règles entrent dans la revue de code et, quand c’est possible, dans l’analyse statique.

Semaines 3 et 4 : consolider deux frontières

Deux modules douloureux reçoivent une façade, des cas d’usage nommés et des tests de contrat. Les entrées, sorties, dépendances et responsabilités sont documentées dans le code. Une transaction critique et un traitement asynchrone sont rejoués avec leurs scénarios d’échec.

Le pipeline exécute les tests ciblés par changement tout en conservant la suite globale. L’instrumentation ajoute temps de réponse, erreurs et files par capacité. Le rollback d’une migration compatible est testé dans un environnement proche de la production.

Semaines 5 et 6 : arbitrer sur les preuves

Une autre personne modifie une règle dans chaque module sans aide orale. L’équipe mesure le délai, les fichiers touchés et le temps de diagnostic d’un échec provoqué. Les dépendances restantes sont classées : acceptées, à réduire ou bloquantes.

Trois issues sont possibles : maintenir le monolithe renforcé, isoler davantage un module interne, ou préparer l’extraction d’une capacité dont l’autonomie est démontrée. La décision inclut un owner, un budget, un seuil d’arrêt et une date de réévaluation.

• Prioriser les frontières qui provoquent des incidents ou ralentissent les changements.
• Automatiser les règles de dépendance au lieu de compter sur la mémoire.
• Séparer les tâches longues avec des workers avant de séparer tout le domaine.
• Tester transactions, concurrence, retry et rollback sur des cas réels.
• Extraire uniquement une capacité stable dont l’équipe accepte l’exploitation complète.

Approfondir les choix Symfony

Pour comparer les architectures au-delà d’un seul cas, l’arbitrage entre monolithe modulaire et microservices met en regard autonomie, contrats et exploitation.

La structuration d’un projet Symfony lorsque le domaine grossit détaille les responsabilités internes. Lorsque certains traitements doivent quitter la requête HTTP, le cadrage de Messenger pour le run complète ce travail.

Conclusion : garder le choix réversible

Pour le maintien d’un monolithe Symfony, le vrai enjeu consiste à transformer une impression en décision reprise par le produit, la technique et l’exploitation. La preuve garde visibles l’hypothèse, la limite et la responsabilité.

Le rapprochement entre une application métier portée par une équipe avec des règles fortement transactionnelles et un module à cadence distincte qui surcharge chaque déploiement global fournit deux cas concrets complémentaires : chemin attendu et exception coûteuse à surveiller.

Pour le maintien d’un monolithe Symfony, la décision peut réduire, différer ou confirmer le périmètre, mais elle conserve un seuil local, un owner et une procédure de repli. Elle ne garantit pas le résultat ; elle permet de corriger sans reconstruire l’historique.

Pour inscrire le maintien d’un monolithe Symfony dans une trajectoire de développement web sur mesure, notre équipe peut vous aider à cadrer les scénarios, auditer les contrats et structurer un premier lot vérifiable avec les personnes qui assureront le run.