Votre développeur est parti, l'agence ne répond plus, et personne ne sait dire dans quel état est le code. Je commence par regarder pour de bon, puis je vous dis ce qui se garde, ce qui se répare et ce qui se jette.
Une reprise ne se décide pas sur un devis, elle se décide sur un état des lieux : ce qui est là, ce qui manque, ce qui vous appartient encore. Tant que ce travail n'est pas fait, tout chiffrage est une promesse en l'air, et vous en avez probablement déjà reçu.
Je travaille seul et de bout en bout, ce qui compte particulièrement ici : la personne qui lit votre code est celle qui le tient ensuite. Vous n'aurez pas à réexpliquer votre projet à chaque nouvel interlocuteur, ni à espérer que l'audit a bien été transmis à quelqu'un.
Cet état des lieux a une forme concrète, et je l'ai publiée : ce que je lis avant de dire oui, et pourquoi le plus gros risque est presque toujours en dehors du dépôt. Vous saurez à quoi ressemble le document avant de le commander.
Je lis le code, je fais tourner l'application, je regarde les versions, les tests, les dépendances abandonnées et les failles connues. Vous recevez un audit de code écrit : ce qui se garde, ce qui se répare, ce qui se réécrit, et dans quel ordre. Il est facturé à part et ne vous engage à rien pour la suite.
Dépôt de code, hébergement, base de données, nom de domaine, comptes de service : une reprise commence souvent par retrouver des accès que plus personne ne détient. J'en fais l'inventaire et je remets tout à votre nom, avant d'écrire la moindre ligne.
Bug bloquant, production qui tombe, mises à jour de sécurité oubliées depuis trois ans : ça se traite tout de suite, séparément du reste. Une application qui tient debout se reprend beaucoup mieux qu'une application en flammes, et remettre le service en ligne ne demande pas d'avoir déjà tout compris.
Le socle assaini, les évolutions reprennent là où elles s'étaient arrêtées. Dette technique, montée de version Symfony et nouvelles fonctionnalités avancent alors par tranches livrées et visibles, plutôt qu'au bout de six mois de chantier dont vous ne voyez rien.
Vitrine & réservation bien-être
Refonte complète du site d'un praticien bien-être : présentation des soins, prise de rendez-vous en ligne et back-office d'administration. Symfony 8 + Tailwind.
Boilerplate SaaS pour Symfony
Boilerplate commercial pour lancer un SaaS Symfony sans réinventer l'infrastructure : authentification (magic links, 2FA), facturation Stripe & Lemon Squeezy, multi-tenant avec équipes et rôles, dashboard admin (MRR, churn), chat IA en streaming. Suite de tests qui rejoue des cycles de facturation complets depuis des webhooks signés, PHPStan au niveau maximum sans aucune dérogation.
SaaS · organisation du foyer
Application de répartition équitable des tâches ménagères en famille : PWA installable, notifications push, abonnements Stripe et répartition des points entre membres du foyer.
Presque toujours. Même sans documentation ni ancien prestataire joignable, le code, la base de données et l'hébergement racontent l'essentiel : c'est long à lire, ce n'est pas mystérieux. Ce qui bloque réellement une reprise, c'est de ne plus avoir accès au dépôt ou au serveur. On commence donc par là, et je vous dis très vite si quelque chose est perdu pour de bon.
Reprendre, dans la grande majorité des cas. Une réécriture repart de zéro sur des règles métier qui ne sont écrites nulle part ailleurs que dans le code existant, et se paie deux fois : une fois pour refaire, une fois pour redécouvrir ce qu'on avait oublié en route. Je ne propose une réécriture que quand je peux montrer pourquoi, et ça reste minoritaire.
Un à deux jours dans la plupart des cas, à 650 € par jour. Vous repartez avec le document, que vous me confiiez la suite ou non : c'est la seule façon d'obtenir un avis qui ne dépende pas de la mission qu'il justifierait. Les travaux se chiffrent ensuite au forfait, puisqu'à ce moment-là le périmètre est enfin connu.
PHP est mon terrain depuis dix-huit ans : Symfony de la version 2 à la version 8, mais aussi du PHP sans framework, qui représente une bonne part des applications à reprendre. PostgreSQL et MySQL derrière, Apache et Debian pour l'hébergement. Quand un projet demande une compétence que je n'ai pas, je le dis au premier échange plutôt qu'au troisième mois.
C'est le cas de départ le plus fréquent, et ce n'est pas rédhibitoire. Un code sans tests, sans conventions et truffé de raccourcis reste un code qui a fait tourner votre activité : il se sécurise par étapes, en commençant par écrire des tests là où ça fait mal, avant d'y toucher. Ce qui me ferait renoncer, c'est un projet dont plus personne ne sait ce qu'il doit faire.
La même chose que si je l'avais écrit : je livre, je déploie, je documente, et je reste joignable pour la suite. J'édite mes propres applications sur cette stack et elles tournent en production tous les jours, donc la maintenance n'est pas pour moi une corvée d'après-mission : elle se prolonge dans un contrat de maintenance mensuel si vous le souhaitez, ou elle s'arrête là si vous préférez tenir l'application vous-même.
Décrivez la situation en quelques lignes : ce que fait l'application, depuis quand elle est à l'arrêt, et ce à quoi vous avez encore accès. Je réponds sous 24 h, avec un avis franc, y compris quand la réponse est qu'il ne faut pas reprendre.