Gestion & Stratégie. Agence de développement web : le sauvetage du projet de Marc

Agence de développement web: le sauvetage du projet de Marc

Le chiffre ne décrit pas une fatalité technique: il décrit une dérive non détectée, puis tolérée, jusqu’au point où chaque livraison casse autre chose.

Le projet de Marc est un cas typique, reconstitué à partir de situations que les agences techniques rencontrent régulièrement: une application web déjà en production, des fonctionnalités inachevées, un prestataire initial absent ou remplacé, une dette technique devenue opaque et un backlog qui mélange incident critique, demande commerciale et idée de dernière minute. Le système compile parfois. Il ne se pilote plus.

Une agence de développement web compétente ne commence pas par promettre une « refonte moderne ». Elle commence par mesurer. Temps de réponse, taux d’erreur, couverture de tests, état des dépendances, surface d’attaque, structure des données, coût réel de chaque évolution. Sans cette phase, reprendre un projet web revient à modifier une allocation mémoire sans connaître le cycle de vie des objets: cela peut sembler fonctionner jusqu’au prochain pic de charge.

Le diagnostic: pourquoi les projets web dérapent réellement

Un projet ne dérape pas parce qu’il contient quelques bugs. Un bug isolé se corrige. La dérive commence lorsque les défauts sont structurels et que personne ne dispose d’une vue fiable sur le système.

Dans le cas de Marc, les symptômes seraient immédiatement reconnaissables par n’importe quel CTO ou chef de projet technique:

• des fonctionnalités livrées sans critères d’acceptation stables;
• un backlog sans priorisation réelle, où une anomalie de paiement côtoie une retouche de libellé;
• des environnements de développement, de recette et de production non alignés;
• des mises en production manuelles, faites à partir d’archives ou de branches locales;
• une base de code PHP dont le comportement dépend d’effets de bord, de variables globales ou de services surchargés;
• des dépendances Composer vieillissantes et parfois incompatibles avec la version du runtime;
• des accès de production distribués à plusieurs intervenants, sans journalisation exploitable;
• aucune mesure de performance disponible avant que les utilisateurs signalent une lenteur.

Le problème n’est pas seulement logiciel. Plus de 60 % des échecs de projet sont associés à des défauts de communication ou de gestion. Cela ne signifie pas qu’il faut résoudre une panne de base de données par une réunion. Cela signifie qu’un système technique sans gouvernance produit mécaniquement des décisions contradictoires.

Une demande urgente contourne le backlog. Une correction est appliquée directement en production. Une estimation devient un engagement ferme alors que le périmètre n’est pas défini. Trois semaines plus tard, l’équipe constate que le budget a été consommé sans diminution visible du risque.

Un projet en difficulté n’a généralement pas un problème de vitesse. Il a un problème d’ordre d’exécution.

L’externalisation du développement web est souvent envisagée trop tard, lorsque le client cherche une équipe capable de « finir rapidement ». Cette formulation est mauvaise. Une agence appelée en reprise ne reprend pas une liste de tickets. Elle reprend un passif: code, données, contrats d’interface, habitudes de déploiement et arbitrages non documentés.

Le premier livrable utile n’est donc pas une fonctionnalité. C’est une photographie du risque.

L’audit technique: cartographier la dette et les failles

L’audit d’une application ne se résume pas à passer un analyseur statique et à produire un PDF de quarante pages. Son objectif est opérationnel: décider ce qui peut rester, ce qui doit être isolé, ce qui doit être corrigé immédiatement et ce qui ne mérite plus d’investissement.

Pour une application PHP, l’audit sérieux commence par le runtime et la chaîne d’exécution. Version de PHP, configuration FPM, OPcache, limites mémoire, timeouts, workers, stratégie de session, comportement du cache, connexions aux services externes. Une application peut avoir un code acceptable et s’effondrer simplement parce que le nombre de processus FPM, les limites de mémoire et les pools de connexion ne correspondent pas à sa charge.

Vient ensuite la lecture de la base de code. Pas une lecture linéaire. Une lecture par points de rupture:

1. Entrées du système. Contrôleurs HTTP, commandes CLI, webhooks, tâches planifiées, imports de fichiers. C’est là que se concentrent les données non fiables et les déclencheurs de traitements coûteux.

2. Couches métier. Une logique métier dispersée entre contrôleurs, listeners, templates et requêtes SQL brutes indique une application difficile à faire évoluer. Le problème n’est pas esthétique: l’absence de frontières fait exploser le coût de modification.

3. Accès aux données. Requêtes N+1, index absents, transactions trop longues, chargements complets de tables, sérialisation excessive d’entités ORM: ces défauts ne se voient pas toujours à faible trafic. Ils deviennent critiques lorsque la volumétrie augmente.

4. Typage et contrats. Un code PHP sans typage strict, avec tableaux associatifs omniprésents et retours implicites, masque les ruptures de contrat jusqu’à l’exécution. L’analyse statique est alors moins un outil de conformité qu’un détecteur de zones sans garantie.

5. Dépendances. Un composer.lock obsolète, des bibliothèques abandonnées ou des extensions PHP spécifiques à un ancien serveur peuvent rendre chaque mise à jour risquée. Il faut distinguer la dépendance simplement ancienne de la dépendance vulnérable ou bloquante.

6. Tests et observabilité. L’absence de tests n’implique pas automatiquement une réécriture. Elle impose en revanche de construire des tests de caractérisation autour des flux sensibles avant toute modification profonde. Sans logs corrélés, traces et métriques, la production reste un système opaque.

L’audit fonctionnel doit avancer en parallèle. Une agence de développement web ne peut pas stabiliser une plateforme dont personne ne sait précisément quelles règles produisent quel résultat. Il faut cartographier les parcours qui ont une valeur métier directe: inscription, authentification, commande, paiement, calcul de prix, synchronisation ERP, génération de documents, droits d’accès.

Le résultat doit être lisible par la direction technique comme par le product owner. Pas une note vague du type « code à améliorer ». Une matrice de décision.

L’audit ne doit pas devenir un délai sans fin. Son rôle est de réduire l’incertitude assez vite pour lancer les premiers correctifs sans commettre d’irréversible. Une semaine d’analyse peut suffire à identifier les risques dominants sur une application compacte. Une plateforme avec plusieurs services, synchronisations et règles métier nécessite davantage. Le bon indicateur n’est pas la durée de l’audit. C’est la capacité à produire des arbitrages explicites.

Stabiliser avant de transformer

La confusion la plus coûteuse consiste à appeler « refonte » tout changement nécessaire. Une réécriture complète paraît rationnelle lorsque le code est médiocre. Elle l’est rarement à court terme.

Réécrire depuis zéro supprime le code visible. Elle ne supprime ni les règles métier implicites, ni les anomalies historiques devenues des comportements attendus, ni les dépendances externes, ni les données incohérentes. Elle ajoute en revanche une longue période pendant laquelle l’ancien système doit continuer de fonctionner tandis que le nouveau tente de le reproduire.

La stratégie de sauvetage efficace est généralement progressive: stabiliser, isoler, remplacer par segments. Cela exige une discipline stricte.

Couper les sources de variabilité

Avant d’optimiser, il faut empêcher le système de changer de manière incontrôlée. Les premières opérations sont peu spectaculaires, mais elles déterminent la suite:

• centraliser le code dans un dépôt Git avec une politique de branches minimale;
• interdire les modifications directes sur l’environnement de production;
• reconstruire un environnement de recette représentatif, données sensibles exclues ou anonymisées;
• définir une chaîne CI/CD qui exécute au moins linting, analyse statique, tests disponibles et déploiement reproductible;
• journaliser les erreurs applicatives avec un identifiant de requête;
• surveiller les métriques de saturation: CPU, mémoire, files d’attente, temps de réponse, erreurs 5xx, requêtes SQL lentes;
• sécuriser les secrets et supprimer les identifiants dispersés dans le code ou les fichiers de configuration versionnés.

La stabilisation ne signifie pas « ne plus livrer ». Elle signifie livrer moins de choses, avec davantage de contrôle. Un projet qui brûle du budget à cause des régressions ne sera pas sauvé par une cadence de livraison plus élevée.

Mesurer le goulot, pas l’impression de lenteur

Sur PHP, les problèmes de performance sont souvent attribués au langage alors qu’ils se situent ailleurs: SQL non indexé, appels HTTP synchrones, génération de documents dans le cycle de requête, cache mal invalidé, upload traité en mémoire, fichier de session verrouillé trop longtemps.

Une agence technique doit établir une ligne de base. Par exemple:

• percentile de latence sur les parcours critiques;
• taux d’erreur par endpoint;
• nombre de requêtes SQL et durée cumulée par requête HTTP;
• consommation mémoire maximale d’un worker;
• taux de cache et coût d’invalidation;
• temps de traitement des tâches asynchrones;
• volume et âge des files d’attente.

Le benchmark utile n’est pas une démonstration synthétique de milliers de requêtes sur une page vide. C’est une mesure reproductible sur les flux qui génèrent du chiffre d’affaires, bloquent des utilisateurs ou saturent l’infrastructure.

Tant qu’un ralentissement n’est pas corrélé à une trace, une requête ou une allocation, ce n’est pas un diagnostic. C’est une hypothèse.

Refactorer autour des flux à risque

Le refactoring doit suivre le risque métier et le coût opérationnel, non l’attrait d’une architecture idéale. Reprendre un projet web consiste souvent à extraire progressivement les points les plus instables.

Un monolithe PHP peut rester un monolithe. S’il dispose de frontières internes claires, de tests, d’un déploiement reproductible et d’une base de données maîtrisée, il sera plus fiable qu’une pseudo-architecture distribuée dont chaque service ajoute une dépendance réseau.

Les chantiers qui produisent généralement un gain rapide sont les suivants:

• remplacer les traitements synchrones longs par des jobs asynchrones avec reprise contrôlée;
• encapsuler les intégrations externes derrière des contrats stables;
• extraire les règles de calcul ou de validation des contrôleurs;
• réduire les objets hydratés inutilement par l’ORM;
• introduire le typage strict sur les nouveaux modules et les zones refactorées, sans bloquer tout le code existant;
• écrire des tests de non-régression sur les règles à forte valeur;
• supprimer les chemins morts et les drapeaux fonctionnels devenus permanents.

Le garbage collector PHP ne compensera jamais une application qui charge un catalogue entier en mémoire pour rendre vingt résultats. L’optimisation est d’abord une discipline de volume, de cycle de vie et d’I/O.

Pilotage agile: remettre le backlog sous contrainte

Une reprise échoue souvent après un audit techniquement juste, parce que le backlog reste inchangé. Chaque partie prenante conserve ses urgences. L’agence reçoit des demandes contradictoires. La dette technique redevient une ligne abstraite que l’on reporte au sprint suivant.

Le backlog doit devenir un instrument de décision, pas un entrepôt de tickets.

Pour cela, chaque élément doit porter quatre informations minimales: le problème observé, la valeur ou le risque associé, la condition de validation et la dépendance éventuelle. « Corriger la lenteur » ne veut rien dire. « Ramener le traitement de validation de commande sous le seuil convenu pour les paniers standards, sans modifier le calcul de taxe » est déjà exploitable.

La priorisation ne se limite pas au revenu potentiel. Une correction de sécurité, une migration de dépendance critique ou un pipeline de déploiement peut ne produire aucune fonctionnalité visible. Elle réduit pourtant la probabilité d’un arrêt ou d’une régression coûteuse.

Dans une collaboration agence technique saine, le backlog sépare au moins trois catégories:

1. Le blocage opérationnel. Incidents, failles, erreurs de données, saturation, pertes de transaction. Ces sujets passent avant le reste.

2. La consolidation. Tests de caractérisation, observabilité, refactoring local, migration de version, automatisation du déploiement. Ce travail réduit le coût des livraisons suivantes.

3. L’évolution produit. Nouvelles fonctionnalités, améliorations de parcours, intégrations, demandes commerciales. Elles avancent lorsque leur périmètre est suffisamment défini et que leur impact technique est compris.

Cette séparation évite une fraude intellectuelle courante: faire passer une dette de plusieurs années dans une estimation de fonctionnalité, puis conclure que l’équipe est lente. L’équipe ne ralentit pas. Elle paie le passif.

Pour choisir un prestataire PHP dans ce contexte, le bon signal n’est pas un catalogue de technologies. C’est sa manière de répondre à trois questions: que mesure-t-il en premier, que refuse-t-il de modifier sans test ou sauvegarde, et comment justifie-t-il l’ordre des travaux? Un prestataire qui annonce immédiatement une date de livraison sans demander accès aux logs, au code, aux environnements et au backlog ne pilote rien. Il vend une estimation sans modèle.

Communication et gouvernance: réduire le bruit de décision

Le facteur humain ne remplace pas l’analyse technique. Il conditionne sa mise en œuvre.

Plus de 60 % des échecs associés à la communication ou à la gestion ne renvoient pas à un manque de bonne volonté. Ils renvoient à un système de décision flou. Qui arbitre entre une fonctionnalité commerciale et une dette bloquante? Qui valide que le périmètre a changé? Qui accepte un risque de sécurité temporaire? Qui peut déclencher un rollback?

Sans réponses nominatives, l’agence accumule les validations partielles, les messages contradictoires et les demandes hors circuit. Le projet produit alors du débit apparent, mais pas de stabilité.

Une gouvernance minimale suffit souvent:

• un responsable produit capable de trancher sur la valeur et le périmètre;
• un référent technique mandaté pour valider les choix d’architecture et les risques;
• un rythme court de revue des métriques, incidents et priorités;
• une décision écrite pour chaque arbitrage qui modifie coût, délai ou niveau de risque;
• une définition claire de ce qui constitue une livraison terminée: code versionné, tests exécutés, déploiement traçable, supervision active.

Le rôle de l’agence n’est pas de prendre le pouvoir sur le produit. Il est de rendre visible le coût des décisions. Ajouter une intégration externe peut être simple sur une maquette et complexe en production si elle implique idempotence, reprise sur erreur, authentification, quotas, gestion des doublons et réconciliation des données. Cette différence doit apparaître avant l’engagement, pas après.

Une reprise propre transforme aussi la relation contractuelle. Le forfait global, lorsque le périmètre est instable et l’état du code inconnu, pousse à masquer les difficultés jusqu’à ce qu’elles deviennent impossibles à absorber. Un fonctionnement par jalons, avec objectifs mesurables et réévaluation du backlog, est généralement plus cohérent avec la réalité d’un sauvetage.

Le verdict: sauver le système, pas défendre l’existant

Le projet de Marc ne serait pas redressé par une promesse de vélocité ou par une nouvelle couche de design. Il le serait par une séquence rigoureuse: audit, sécurisation des flux critiques, observabilité, pipeline de déploiement, backlog sous contrainte, refactoring ciblé.

Une agence de développement web utile en reprise ne vend pas une réécriture réflexe. Elle identifie ce qui doit être conservé, encapsulé, corrigé ou supprimé. Elle chiffre l’incertitude au lieu de la maquiller. Elle mesure avant d’optimiser et stabilise avant d’étendre le périmètre.

Verdict: refactoring progressif et pilotage serré, à utiliser en production. Réécriture complète immédiate, à refuser tant que l’audit n’a pas démontré qu’aucune trajectoire incrémentale n’est viable.