Mission d’audit, relance et transmission technique
Chalon-sur-Saône (71) Budget : 5 000 à 10 000 € Publié le 19/02/26
Description de la mission
MISSION D’AUDIT, RELANCE ET TRANSMISSION TECHNIQUE
Symfony / Sylius – Environnement neutre
Contexte et objectif
L’objectif de la mission est triple :
Vérifier la relançabilité complète de la solution sur infrastructure vierge.
Structurer une autonomie technique interne progressive.
Sécuriser l’exploitation avant toute évolution fonctionnelle.
La mission est organisée en binôme technique :
Prestataire freelance senior : expertise Symfony/Sylius, audit, méthodologie, relance.
Collaborateur interne : participation active, apprentissage structuré, continuité technique interne.
Principe directeur :
Le prestataire pilote la relance technique.
Le collaborateur interne participe activement et documente.
Le commanditaire conserve la gouvernance technique et infrastructure.
Le cadre proposé peut naturellement être ajusté après échange afin d’intégrer les recommandations méthodologiques du prestataire.
Phase 1 – Session de cadrage (½ journée)
Objectif
Préparer méthodiquement la séquence de relance prévue les 3 et 4 mars.
À ce stade, certains accès techniques peuvent être partiels. L’objectif est d’établir un cadre technique précis et complet.
Attendus de la session
Définition exhaustive des éléments indispensables à la relance.
Spécification précise du serveur vierge (infrastructure cible).
Définition de la stack technique requise (versions exactes PHP, MySQL, Redis, Elasticsearch, etc.).
Méthodologie de relance recommandée.
Identification des risques techniques anticipables.
Définition d’une grille de contrôle utilisée lors du crash-test.
Implication du collaborateur interne
Présence active.
Prise de notes structurée.
Reformulation des prérequis.
Compréhension des enjeux techniques.
Livrable attendu
Document structuré comprenant :
Liste des livrables techniques attendus.
Stack technique cible.
Services requis.
Points critiques identifiés.
Méthodologie détaillée de relance.
Phase 2 – 3 et 4 mars
Audit et crash-test sur serveur vierge
Objectif
Relancer intégralement la solution sur infrastructure neutre et établir un diagnostic technique formalisé.
Étape 1 – Contrôle des éléments fournis
Vérification structurée :
Dépôt Git complet et cohérent.
Fichier docker-compose fonctionnel.
Fichiers lock (composer.lock, yarn.lock) alignés.
Dump base de données exploitable.
Dossier médias complet.
Fichier .env exploitable.
Migrations Doctrine synchronisées.
Absence de dépendances privées non transférées.
Étape 2 – Installation et build
Installation de la stack Docker.
Paramétrage des services.
Import de la base.
Injection des configurations.
Lancement de l’application.
Étape 3 – Tests critiques
Frontend opérationnel.
Back-office accessible.
Authentification.
Tunnel de commande.
Paiement en environnement sandbox.
Exports.
Elasticsearch.
Workers / tâches planifiées.
Test de restauration de base.
Rôle du collaborateur interne pendant le crash-test
Observation active.
Reproduction partielle des étapes.
Compréhension de l’architecture.
Documentation des procédures.
Capacité à expliquer le processus en fin de session.
Rapport attendu en fin de mission (4 mars)
Document synthétique comprenant :
Temps réel de relance.
Difficultés rencontrées.
Éléments bloquants éventuels.
Points de fragilité.
Niveau de maturité technique observé.
Recommandations court terme.
Phase 3 – Transmission et tutorat
(Déclenchée uniquement si la relançabilité est validée)
Objectif
Construire une autonomie technique interne réelle.
Durée indicative : 6 à 8 demi-journées.
Module 1 – Architecture
Structure Symfony.
Entités Doctrine clés.
State machines Sylius.
Flux CRM ↔ Sylius.
Elasticsearch.
Workers.
Livrable : schéma d’architecture documenté.
Module 2 – Exploitation
Lecture des logs.
Debug.
Gestion du cache.
Réindexation.
Sauvegarde.
Restauration.
Livrable : guide d’exploitation interne.
Module 3 – Sécurité et stabilité
Gestion des secrets.
Mise à jour des dépendances.
Sauvegardes automatisées.
Procédure de disaster recovery.
Livrable : procédure de continuité technique.
Module 4 – Intervention encadrée
Modification simple supervisée.
Test en environnement isolé.
Déploiement contrôlé.
Procédure de rollback.
Livrable : validation d’autonomie technique du collaborateur interne.
Phase 4 – Mise à niveau structurante
(Déclenchée uniquement si Phase 2 validée)
Objectif : sécurisation, performance et simplification sans réécriture majeure.
4.1 Sécurisation technique
Mise à jour des dépendances critiques.
Nettoyage des packages obsolètes.
Vérification de compatibilité des versions.
Stabilisation des workers.
4.2 Optimisation performance
Optimisation du cache.
Optimisation Elasticsearch.
Optimisation Doctrine.
Configuration PHP.
4.3 Nettoyage et simplification
Suppression de code non utilisé.
Clarification des services.
Simplification de la configuration Docker.
Documentation consolidée.
Principe constant
Toute action doit être :
Expliquée.
Compréhensible.
Documentée.
Reproductible en interne.
Discipline post-relance (90 jours)
Après validation de la relance :
Priorité absolue à la stabilité.
Aucun développement non critique.
Environnement isolé obligatoire pour toute évolution.
Documentation systématique.
Revue technique mensuelle.
Gouvernance
Le commanditaire conserve :
Propriété des serveurs.
Compte hébergeur.
DNS.
Facturation.
Accès root de secours.
Le prestataire intervient exclusivement sur le périmètre technique défini.
Toute extension fera l’objet d’un accord distinct.
Estimation budgétaire (base 500 €/jour)
Phase 1 : 250 €
Phase 2 : 1 000 €
Phase 3 : 1 500 à 2 000 €
Phase 4 : 1 500 à 3 000 €
Total potentiel : 4 000 à 6 000 €.
Résultat attendu à trois mois
Stack relançable à volonté.
Autonomie technique interne.
Documentation structurée.
Dépendance externe minimale.
Base saine pour évolutions futures.
