--- title: Comment savoir si ton application est encore maintenable description: Les signaux à vérifier pour savoir si ton application peut encore évoluer, avant de décider quoi que ce soit. category: SaaS & Product format: article pillar: audit-technique tags: audit, maintenabilite, reprise, dette-technique author: Charlie Dallier-Wood publishedAt: 2026-10-20 updatedAt: 2026-10-27 canonical: https://sycode.fr/blog/application-encore-maintenable --- Le 8 septembre 2026, sur une plateforme que j'ai reprise en cours de route, j'ai fait un truc tout bête : j'ai demandé à la base de se reconstruire à partir de zéro. Trente-six fichiers de migration, censés rejouer toute l'histoire du produit. Treize ont échoué. Onze tables sur vingt-cinq ne sont jamais apparues. Et la commande, elle, a affiché un succès en ignorant les trente-six fichiers. C'est la phrase qui porte tout cet article : un système peut te dire qu'il va bien sans que personne ne puisse le vérifier. La plateforme tournait. Des utilisateurs s'y connectaient tous les jours. Rien, dans ce qu'un dirigeant peut voir, n'indiquait quoi que ce soit. > Ce qui tourne et ce qui est vérifiable, ce sont deux choses différentes. Alors voilà ce que je regarde, moi, quand j'arrive sur un produit que je ne connais pas. Pas pour décider de le refaire ou de le réparer — ça, c'est la question d'après. Juste pour savoir où on en est. ## Le système qui annonce un succès qu'il ne peut pas tenir La première question que je pose n'a rien de technique : si le serveur qui héberge ta base disparaît cette nuit, tu repars de quoi ? Sur la plateforme en question, la réponse était « de la chaîne de migrations ». L'hébergement était gratuit, donc sans aucune sauvegarde incluse. Les trente-six fichiers étaient le seul chemin de reconstruction existant, et ce chemin était coupé depuis un moment sans que ça se voie. En l'état, un incident sérieux aurait voulu dire reconstruire les tables une par une à la main, pendant plusieurs jours, sans pouvoir annoncer une date de retour aux clients qui payent. Le truc, c'est que rien ne signalait le problème. La commande de migration répondait « OK ». Un développeur qui la lance en local et qui voit « OK » passe à autre chose, et il a raison de passer à autre chose : c'est l'outil qui ment, pas lui. Si tu veux faire vérifier une seule chose sur ton produit, c'est celle-là. La question se pose en français, elle n'a pas besoin de toi pour être comprise : *est-ce qu'on peut reconstruire la base sur une machine vide, aujourd'hui, et est-ce que ça donne exactement la base de production ?* Une réponse évasive est déjà une réponse. ## Une sécurité qui a l'air branchée n'est pas une sécurité qui fonctionne L'isolation des données au niveau de la base — ce qu'on appelle la RLS — est le cas d'école. Elle s'active d'une case à cocher, elle se voit dans l'interface, et elle peut très bien n'avoir jamais rien refusé. Plusieurs causes se cumulent en général, et aucune n'est visible depuis l'écran : une fonction d'autorisation qui répond trop largement, un rôle qui a gardé des droits qu'on croyait retirés, des règles qui se protègent l'une l'autre par accident. Le résultat, quand ça arrive, c'est que la case reste cochée pendant que la porte est ouverte. En gros, entre « c'est branché » et « ça refuse vraiment », il y a un test à écrire, et personne ne l'écrit spontanément. Sur cette reprise, j'ai fini par poser vingt-huit attentes vérifiées sous un rôle qui n'a pas le droit de contourner les règles. C'est le genre de décision d'architecture qu'on ne défait pas facilement après coup, et j'en parle plus en détail dans [comment choisir son architecture technique](/blog/choisir-architecture-technique-saas). Le même angle mort existe sur les routes d'administration. Une route qui exécute son action sans jamais demander qui appelle se comporte exactement comme une route protégée, tant que personne n'essaie. C'est vérifiable en une demi-journée, et ça ne se voit pas autrement. ## Une sauvegarde qu'on n'a jamais restaurée n'est pas une sauvegarde Je ne vais pas te raconter ça sur un projet client, parce que le meilleur exemple que j'ai, c'est le mien. Le 6 septembre 2026, sur asap.cool, mon propre produit, j'ai voulu tester la restauration d'un backup. La procédure était documentée. Elle ne pouvait pas marcher : le dump chiffré était envoyé tel quel dans l'outil de restauration, qui ne sait pas déchiffrer. En plus, des tables entières manquaient au dump. La case « backups testés » était décochée depuis le mois de mai. Quatre mois pendant lesquels je croyais être couvert, et pendant lesquels je ne l'étais pas. Le jour où j'en aurais eu besoin, j'aurais découvert la panne au pire moment possible, avec des données définitivement perdues sur les tables absentes. Du coup, la question à faire poser sur ton produit n'est pas « est-ce qu'on a des sauvegardes ». C'est : - quand est-ce qu'une restauration complète a été faite pour de vrai, sur une machine vide ; - combien de temps elle a pris, chronométrée ; - ce qui manquait à l'arrivée par rapport à la production ; - qui sait la refaire, à part la personne qui l'a écrite. Une sauvegarde non restaurée, c'est une ligne de budget qui n'achète rien. Et comme c'est un poste qu'on sous-estime presque toujours au moment du lancement, j'en ai fait un morceau du [coût réel de l'infrastructure d'un SaaS](/blog/cout-reel-infrastructure-saas). ## Le bug qu'on ne voit qu'à la relecture, jamais à l'usage Il y a une catégorie de défauts qui ne se manifestent jamais à l'usage normal. Personne ne s'en plaint, aucun ticket n'est ouvert, et ils coûtent quand même. Quand j'ai repris le prototype de [GoPronos](/case-studies/gopronos) le 22 mai 2026, l'application marchait : on pronostiquait, on voyait un classement. En quarante commits, ce qu'on a changé avec le client, ce sont les règles du jeu qui vivaient dans l'écran au lieu de vivre dans la base. Les pronostics ne se verrouillaient pas au coup d'envoi côté serveur. Les choix des autres joueurs n'étaient pas masqués. Les rôles n'étaient pas vérifiés en base. Tant que la fermeture des paris dépend de l'écran, un classement contesté ne peut pas être défendu, et un jeu de pronostics ne vaut que ce que vaut son classement. C'est le genre de chose qui se règle avant l'ouverture au public ou qui ne se règle plus du tout. Là, ça a été réglé avant, et le produit est sorti sur les stores. Même famille, autre projet : sur la plateforme reprise dont je parlais plus haut, en ramenant cent vingt-deux accès à la base vers un accès unifié, j'ai découvert au passage qu'une structure voyait les demandes des autres structures. Rien ne l'indiquait à l'écran. Des données commerciales d'un client visibles par un autre client, qui se trouvent parfois être concurrents sur le même marché. ## Beaucoup de commits ne veut pas dire un système sain Reste une idée tenace : un historique fourni, beaucoup de code, beaucoup de fonctionnalités, ce serait bon signe. J'ai la réponse chez moi. Entre décembre 2025 et janvier 2026, j'ai écrit mille soixante-seize commits sur asap-website-builder. Zéro utilisateur. Au même moment, Deviso.pro en comptait cinq cent cinquante-huit, avec des utilisateurs payants dessus. C'est Deviso que j'ai protégé quand j'ai décidé de repartir sur une nouvelle base, et c'est l'autre que j'ai laissé tomber. Un système qui a doublé le volume de code d'un autre sans produire un seul client a consommé des mois de développement pour rien. La maintenabilité ne se lit pas au volume, elle se lit à ce que le système te permet encore de faire cette semaine. Si tu veux un repère : un produit sain, c'est un produit où une évolution simple reste simple six mois après le lancement, et c'est exactement ce que je cherche à protéger quand je [définis un MVP](/blog/definir-un-mvp). Au passage, tu vas croiser des chiffres sur la dette technique. Stripe, en 2018, mesurait environ 42 % du temps des développeurs passé dessus ; McKinsey, en 2020, évaluait la dette à 20 à 40 % de la valeur du parc technologique. Ces deux études portent sur de grandes entreprises, pas sur un produit de fondateur solo. Je les cite pour le cadrage, je ne les applique pas à ton cas. ## Les garde-fous écrits valent mieux que les bonnes intentions Le dernier signal est celui que je regarde en premier quand tout le reste a l'air correct : est-ce que ce système a des limites écrites, ou juste des habitudes dans la tête de quelqu'un ? Sur asap.cool, j'ai un fichier `NEVER.md` qui liste ce à quoi on ne touche pas. Et j'ai une revue croisée systématique sur tout ce qui a une valeur légale. C'est cette revue qui a requalifié un « export FEC conforme » en « journal des ventes au format FEC », avant livraison. Sans elle, un document présenté comme conforme à une norme comptable partait tel quel chez un client : un risque juridique direct, et pour moi, une phrase impossible à rattraper après coup. Chez [Optimo France](/case-studies/optimo-france), le 10 mai 2026, on a mené l'audit de sécurité nous-mêmes, avant d'avoir un problème. Il en est sorti des factures accessibles en changeant simplement un identifiant dans l'URL, des clés d'API en clair dans un fichier de configuration et des sauvegardes non chiffrées. Tout ça était exploitable par n'importe qui ayant deviné une adresse. Corrigé avant le moindre incident : sauvegardes chiffrées sur un stockage européen, nettoyage des données personnelles dans les journaux, cookie sécurisé. La différence entre les deux histoires de cette section et celles d'avant, c'est le moment où le problème a été trouvé. Un système maintenable, c'est d'abord un système qui a de quoi se faire attraper. ## Ce que je fais, moi Je ne fais jamais confiance à un système parce qu'il tourne. Je vérifie qu'il peut se reconstruire — une migration rejouée sur une base vide, une sauvegarde effectivement restaurée — et je préfère un garde-fou écrit à la mémoire de la personne qui a codé le truc. Parce que cette personne finit toujours par partir, et c'est un sujet à part entière, la dépendance à un seul développeur. Tout ce que je viens de décrire, ça te dit où tu en es. Ça ne te dit pas encore s'il faut réparer ou repartir de zéro. Si tu veux qu'on regarde ensemble ce qui, dans ce que tu as, tient et ce qui ne tient pas, prends un créneau de trente minutes et on fait le tour — c'est exactement le point de départ d'un [audit technique](/offres/audit-technique).