Comment nous avons sauvé un produit SaaS après un transfert d’agence raté

Le scénario ci-dessous est une étude de cas composite construite à partir de schémas que Symilars observe à plusieurs reprises lors des prises de contrôle. Ce n’est pas un seul client réel et nommé, et aucune des statistiques ci-dessous ne doit être lue comme des statistiques vérifiées concernant une seule entreprise. Nous le présentons ainsi parce que le motif lui-même est la partie utile : si vous regardez actuellement une base de code que vous n’avez pas construite, vous demandant si elle peut même être sauvegardée, la forme de cette histoire est plus instructive que les chiffres d’une seule entreprise.

La situation

Le client était une plateforme logistique SaaS de série A — un outil de planification d’itinéraire et de visibilité de flotte vendu aux opérateurs de transport et de livraison de taille moyenne. L’équipe fondatrice avait de bons instincts produit et un vivier croissant de prospects d’entreprise, mais le logiciel derrière le pitch deck avait été développé en 14 mois par une agence externalisée qui, au moment où Symilars a reçu l’appel, était devenue silencieuse.

Les signes avant-coureurs correspondaient presque exactement à ce que nous décrivons dans Comment prendre en charge un projet logiciel raté ou abandonné : des mises à jour sprint qui étaient passées de walkthroughs détaillés à des messages Slack d’une ligne, puis à rien ; un « tableau de bord v2 » promis, presque terminé pendant deux cycles de sortie consécutifs ; et une équipe fondatrice sans CTO, sans personne en interne capable de dire avec certitude ce qui était réellement déployé en production ou ce qui n’existait que dans une branche de stade.

Les fondateurs n’avaient pas de preuve irréfutable. Ils avaient un pressentiment — ce genre de malaise qui naissent lentement et qui vient de trois check-ins manqués et d’une boîte de réception de support remplie de rapports de bugs que l’agence ne triait pas. Ils ont contacté non pas parce qu’ils étaient certains que le projet était abandonné, mais parce qu’ils avaient besoin que quelqu’un leur dise, honnêtement, à quel point c’était grave.

Ce que l’audit a découvert

Avant de citer quoi que ce soit, nous avons mené un audit structuré sur la base de code, l’infrastructure et le pipeline de déploiement — le même processus en quatre étapes décrit dans notre guide de prise de contrôle. Ce qui est revenu, c’est un mélange assez typique de problèmes de blocage, de dette à haut risque et de bruit cosmétique.

Problèmes de blocage :

• Les identifiants de base de données et une clé API de mappage tierce engagés directement dans l’historique des versions du dépôt, tous deux encore actifs
• Aucune sauvegarde automatisée configurée sur la base de données de production — une exportation manuelle existait, six semaines de stagnation
• Un travail critique d’optimisation des routes qui échouait silencieusement sous des tailles de charge utile spécifiques, sans alerte, de sorte que les pannes ne survenaient que lorsqu’un client se plaignait

Dette technique à haut risque :

• Couverture automatisée de test pratiquement nulle — une poignée de fichiers de test structurés sans véritable assertion à l’intérieur
• Une couche API monolithique où la logique métier, les requêtes de base de données et la gestion des requêtes étaient emmêlées dans les mêmes fonctions, ce qui faisait que toute modification d’une fonctionnalité risquait de casser deux entités non liées
• Logique d’authentification et d’autorisation dupliquée sur plusieurs points de terminaison au lieu de centralisée, avec au moins une route manquant complètement de contrôle de propriété
• Dépendances datées d’environ deux ans, plusieurs avec des avis de sécurité publiés

Dettes cosmétiques ou de faible priorité :

• Conventions de nommage et formatage incohérents entre les fichiers clairement écrits par différents sous-traitants au fil du temps
• Code mort provenant d’au moins une branche de fonctionnalité abandonnée qui avait été fusionnée dans la principale

Rien de tout cela n’était inhabituel pris isolément. Ce qui rendait la situation sérieuse, c’était la combinaison : une exposition de sécurité en direct, aucun filet de sécurité de tests pour détecter les régressions, et aucune sauvegarde fiable si quelque chose tournait mal pendant la réparation. Le rapport de conclusions que nous avons remis aux fondateurs était franc sur cette commande — certains éléments devaient être corrigés cette semaine-là, et le reste pouvait attendre.

Le plan : stabiliser avant de construire

L’instinct des fondateurs, compréhensiblement, a été de nous demander simplement de finir le tableau de bord v2 promis par l’agence précédente. Nous avons contesté le séquençage, pas le périmètre. Construire de nouvelles fonctionnalités par-dessus des failles de sécurité non corrigées et un noyau non testé aurait signifié hériter de la même fragilité qui les a menés ici, juste avec notre nom dessus.

Nous avons proposé un plan en trois phases au lieu d’une grande estimation, qui est l’approche que nous recommandons dans toute prise de contrôle :

1. Stabilisation (semaines 1–3): Faire tourner toutes les créances exposées, supprimer les secrets de l’historique des versions, restaurer les sauvegardes automatisées et corriger le travail de route en échec silencieux. Pas de nouvelles fonctionnalités — juste combler les failles qui pourraient couler le produit du jour au lendemain.
2. Foundation rebuild (semaines 4–9): Construire une véritable suite de tests autour des chemins à fort trafic (calcul des routes, facturation et accès aux comptes), refactorer la logique d’autorisation en une couche centralisée, et démêler suffisamment le pire du code API monolithique pour garantir la sécurité des futurs changements.
3. Reprendre le développement des fonctionnalités (semaine 10 à partir de la semaine): Reprendre le tableau de bord v2, désormais au bout du code, l’équipe pourrait vraiment raisonner et changer sans retenir son souffle.

Nous avons fourni aux fondateurs une estimation écrite uniquement pour la phase un, avec des fourchettes approximatives pour les phases deux et trois que nous nous sommes engagés à consolider une fois les conclusions de la première phase confirmées. Cela leur a permis de prendre une vraie décision de go/no-go avec un petit nombre limité au lieu de signer des mois d’incertitudes dès le départ.

L’Œuvre

La première phase avançait vite parce qu’elle le devait. Chaque identifiant de l’historique du dépôt a été tourné dans la première semaine, la clé API fuitée a été révoquée et remplacée, et un calendrier de sauvegarde automatisé approprié a été intégré à l’infrastructure avec une alerte en cas d’échec d’une sauvegarde. L’échec silencieux du travail s’est avéré être une exception simple et non traitée sur des charges utiles dépassant un certain nombre d’arrêts de route — une correction de deux jours une fois que quelqu’un est effectivement allé la chercher, ce que personne dans l’agence précédente n’avait apparemment fait.

La deuxième phase était le travail plus lent et moins glamour qui détermine réellement si un sauvetage tient la route. Plutôt que de tenter une réécriture complète — ce que nous déconseillons généralement à moins qu’une base de code ne soit vraiment irrécupérable — l’équipe a d’abord écrit des tests de caractérisation sur le comportement existant des modules de calcul de route et de facturation, afin que toute refactorisation ultérieure ait un point de comparaison. Ce n’est qu’à ce moment-là que la logique d’autorisation a été consolidée dans une seule couche middleware, fermant au passage la vérification de propriété manquante. La couche API était divisée de manière incrémentale, module par module, plutôt que dans un seul grand cycle perturbateur, précisément pour que le produit reste livrable tout le temps. Les mises à jour de dépendance étaient regroupées et testées isolément, plutôt que comme un énorme coup de version, ce qui a révélé deux changements brisants qui auraient été bien plus difficiles à retracer s’ils avaient été intégrés avec tout le reste.

À la fin de la deuxième phase, environ 60 % des chemins de requête principaux bénéficiaient d’une couverture automatisée significative des tests — pas une couverture complète, ce qui n’était pas l’objectif, mais suffisamment pour qu’un changement de logique de facturation ne nécessite plus de cliquer manuellement sur l’application en espérant que rien d’autre ne casse.

La phase trois paraissait presque ennuyeuse en comparaison, ce qui était le but. Le tableau de bord v2, qui était bloqué pendant deux cycles de sortie sous l’agence précédente, a été lancé en environ cinq semaines, sur une base de code que l’équipe pouvait désormais avancer avec une certaine confiance plutôt qu’avec appréhension.

Le Résultat

Formulée de manière qualitative plutôt qu’avec une précision inventée : la plateforme est passée d’une exposition de sécurité non correcte et sans sauvegarde fiable à une fondation stabilisée et testée en environ trois semaines, puis de la stabilisation à la reprise de la vitesse normale des fonctionnalités en environ dix semaines au total. Les fondateurs ont retrouvé la capacité de répondre à une question basique qu’ils n’avaient pas pu répondre auparavant — « qu’est-ce qui est réellement en production actuellement » — et ont cessé de s’inquiéter personnellement de savoir si le prochain déploiement ferait baisser la facturation.

Tout aussi important, le réseau d’entreprise qui stagnait sur les questions « pouvez-vous nous montrer vos pratiques de sécurité » a recommencé à bouger, car il y avait enfin de vraies réponses à donner.

Ce que cela signifie pour toi

Si vous lisez ceci parce que votre propre situation rime avec celle décrite ici, quelques éléments méritent d’être retenus. Premièrement, un léger malaise concernant la réactivité de votre agence est une raison légitime de demander un second avis — vous n’avez pas besoin de preuve d’abandon pour justifier un audit. Deuxièmement, un audit réel produit une liste de problèmes par paliers, pas un seul verdict du type « tout va bien » ou « brûlez tout » ; La plupart des bases de code héritées sont récupérables, et la plupart de ce qui semble catastrophique dès le premier jour s’avère être une liste séquencée et gérable une fois que quelqu’un lit réellement le code. Troisièmement, résistez à l’envie de revenir directement dans le stage avant que le sol ne soit stable — cela semble plus lent en première semaine et est presque toujours plus rapide en dixième semaine.

Le schéma de cette étude de cas — déclin discret, audit honnête, plan de stabilisation par phases et retour à la vitesse normale — est le même que nous détaillons plus en détail dans Comment prendre en charge un projet logiciel raté ou abandonné, incluant la checklist spécifique d’audit, les étapes de transfert d’accès, et les protections contractuelles qui valent la peine d’être mises en place pour que cela ne se reproduise pas.