D’où vient cette démonstration
J’ai récupéré le code de quelqu’un qui n’était plus là bien plus d’une fois, et souvent sans documentation. Le premier jour, c’est l’inspection et le début du reverse-engineering. C’est là que je sais si je vais avoir du fun, ou si je vais détester chaque seconde à travailler dessus.
Un jour, un TYPO3. Je ne connaissais pas du tout le CMS, aucune expérience sur TypoScript, et une semaine pour faire une refonte complète avec de nouvelles fonctionnalités de recherche, sans passer par des librairies extérieures. À cette époque il n’y avait pas encore d’IA capable de m’aider là-dessus.
C’est là qu’on prouve ce qu’on dit. « Je suis autodidacte », je ne le dis plus en doutant. Pas seulement pour ce TYPO3, pour toutes les reprises que j’ai eu à faire.
Le problème
Vous avez un outil qui tourne, et le prestataire qui l’a posé a disparu. Personne ne répond, les dépendances ont vieilli, et vous vous demandez si quelqu’un peut reprendre derrière lui sans tout casser.
Fabriquer un « projet mal fichu » pour le réparer devant vous serait une mise en scène : j’aurais écrit les deux côtés, et vous le sentiriez. La seule version honnête d’une reprise se fait sur du code que je n’ai pas écrit. J’ai donc pris un vrai logiciel abandonné.
OpenSupports, un système de tickets de support client (PHP et ReactJS, créé par Ivan Díaz et la société OpenSupports, sous licence GPL-3.0). Dernier commit en juin 2022. 91 pull requests ouvertes sans réponse. Et surtout 4 failles de sécurité publiées depuis l’abandon, dont aucune n’est corrigée en amont.
Je me suis penché sur les outils de support, parce que j’en aurai peut-être besoin plus tard. En faisant mon choix, j’ai regardé deux choses.
Est-ce que le projet est encore utilisé malgré l’abandon ? Oui : des chercheurs déposent régulièrement, et récemment, des bugs et des failles dans les issues, dont une notée 9.8.
Est-ce que ce que je reprends va être remarqué par quelqu’un de non technique ? Oui aussi. Une injection SQL, un téléversement, une SSRF donnent un avant/après qui se rejoue en une commande. « J’ai corrigé le typage pour que le lint passe », c’est cool, mais aucun intérêt pour les utilisateurs.
Ce que vous récupérez
Vous récupérez un état des lieux daté, chiffré, et relisible dans deux ans par quelqu’un d’autre que moi. Il dit ce qui est cassé, ce que ça vous fait courir comme risque, et ce que ça coûterait de le réparer.
Vous récupérez aussi la liste de ce que je ne touche pas, et pourquoi. Sur une reprise, c’est souvent la partie la plus utile.
Ce que j’ai trouvé
Une reprise commence par un état des lieux mesuré, avant de toucher à quoi que ce soit. Voici le mien, daté du 8 août 2026, sur le dépôt tel quel.
Le serveur tourne encore. Son runtime PHP 7.0 est en fin de vie depuis 2019. composer audit remonte sept advisories sur trois paquets ; côté front, npm audit en compte 229. La suite de tests PHPUnit passe, avec une erreur pré-existante que je n’ai pas introduite et que je laisse telle quelle. Deux chaînes de build ont pourri faute d’épinglage : le harnais de tests Ruby ne se construit plus, et le front React ne compile sur aucun Node moderne.
Puis j’ai rejoué les failles pour les constater de mes yeux, pas sur parole. Trois se reproduisent de bout en bout : une injection SQL qui élargit la liste des tickets au-delà de vos droits, un téléversement qui accepte un fichier exécutable déguisé, et un diagnostic réseau qu’un visiteur anonyme peut pointer où il veut. Chacune est une CVE publique, datée, notée par des tiers.
Ce que j’ai corrigé, et dans quel ordre
D’abord un filet de sécurité : des tests qui décrivent le comportement existant, y compris celui qui a l’air faux. Tant qu’un client en dépend, c’est une fonctionnalité. Ce filet me dit si une correction casse autre chose.
Sur un autre projet, une fiche ne devait porter qu’une seule photo, à cause de la résolution et de la qualité. Un bug laissait en publier plusieurs à la suite depuis un .zip, et les visiteurs scrollaient horizontalement pour toutes les voir. On en a fait une fonctionnalité, sans le .zip, avec un carousel pour que ce soit plus facilement consultable et un plugin de compression d’image sans perte de qualité ni de résolution.
Ensuite les corrections, par ordre de risque décroissant, un commit par correction :
- Le téléversement (CVSS 9.8). La pièce jointe n’était validée que sur son type de contenu, falsifiable. J’ajoute un contrôle de l’extension calqué sur les types déjà autorisés. Un fichier doit passer les deux.
- L’injection SQL (CVSS 7.1). Un paramètre était collé tel quel dans la requête. Je le lie comme une donnée, avec le mécanisme que les fichiers voisins utilisent déjà. Je n’impose aucune convention nouvelle.
- Le diagnostic réseau (CVSS 5.3). Il restait ouvert aux anonymes après l’installation. Je le referme une fois l’installation faite, sans gêner l’administrateur qui s’en sert légitimement.
Et surtout, ce que je n’ai pas touché. Je n’ai pas monté les dépendances vulnérables de version : sur ce chemin sans tests, le risque de casser un envoi d’e-mail dont un client dépend dépasse le bénéfice. Je n’ai pas rouvert le front React : le remettre à niveau serait une réécriture, pas une reprise. Chaque renoncement est écrit et justifié dans le rapport.
La quatrième faille non plus n’est pas corrigée. Elle porte sur le contrôle d’accès à la liste de supervision, et toute correction que je pouvais écrire changeait un comportement documenté : élever le point d’entrée à staff_3 referme le trou, contredit la permission staff_1 que la documentation annonce, et casse le panneau utilisateurs. C’est une décision de produit, qui revient à un mainteneur. Je l’ai signalée plutôt que corrigée.
Quand c’est une usine à gaz, c’est dur de résister à la tentation de tout refaire. Ce qui l’arrête, c’est le temps et l’argent que le client est prêt à mettre. Donc on garde, et on garde une dette technique. Je ne suis pas fan. Mais je comprends le client qui me dit « tant que ça marche, touche à rien ».
Ce que ça prouve
La comparaison vaut mieux que le récit. Le même relevé, après : les trois failles passent de VULNÉRABLE à CORRIGÉ, le téléversement légitime et le diagnostic administrateur continuent de fonctionner, et la suite de tests reste identique. Aucune régression.
Le rapport de reprise porte l’avant/après chiffré et daté, le détail de chaque correction et de chaque renoncement, plus le script qui rejoue les trois failles. Les quatre correctifs sont regroupés dans une pull request ouverte vers l’auteur d’origine, vérifiable par n’importe qui. Le dépôt étant sans mainteneur depuis 2022, elle restera peut-être sans réponse ; elle n’en est pas moins publique, et les failles concernées étant déjà publiées, elle ne divulgue rien de neuf.
J’ai aussi été celui qui s’en va. J’ai laissé derrière moi de la documentation technique et le reverse-engineering que j’avais fait. Le problème n’a jamais été la documentation. Le problème, c’est une surcouche que personne ne veut toucher, et que celui qui y touche n’a de toute façon pas le temps de reprendre en entier.
Chez vous, je travaille pareil : mesurer avant de toucher, corriger dans l’ordre du risque, laisser en place ce qui marche, et vous rendre un état des lieux que vous pourrez relire dans deux ans.