Mission d’audit, relance et transmission technique

  Chalon-sur-Saône (71)      Budget : 5 000 à 10 000 €      Publié le 19/02/26

Informatique     

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.