Reprendre un projet web abandonné

Votre projet web abandonné est payé pour une part, écrit pour une part, et il n’a jamais été ouvert à vos utilisateurs. Le montant qu’il faut sortir pour le finir ne se déduit pas du seul travail resté à écrire. Une seconde ligne s’y ajoute, celle du rattrapage, et elle se calcule depuis une donnée que vous êtes seul à détenir, la date à laquelle le développement s’est arrêté. Pendant cet arrêt, le code source est resté tel quel, alors que tout ce à quoi il est raccordé a continué d’avancer. Le certificat qui affichait le cadenas sur l’adresse de votre recette est valable 90 jours par défaut chez Let’s Encrypt, et la version du socle sur lequel votre développement a été écrit porte une date de fin de support publiée à l’avance. Voici comment dater votre projet, ce que cette date rend caduc, et ce qu’elle laisse intact.

Pendant l’arrêt, le code reste stable et son environnement avance

Le code écrit pour vous ne se dégrade pas de lui-même. Un calcul enregistré il y a deux ans produit encore le même résultat aujourd’hui, sur les mêmes données. Ce qui bouge pendant un arrêt, c’est tout ce à quoi ce code source est raccordé, la version du langage qui l’exécute, les briques logicielles écrites par d’autres qu’il appelle et que les développeurs nomment ses dépendances, les comptes de service ouverts pour lui chez des prestataires extérieurs, le certificat qui fait afficher son adresse sans avertissement dans un navigateur. Chacun de ces éléments suit un calendrier propre, tenu par une équipe qui ne connaît ni votre dossier ni son budget, et aucun de ces calendriers ne s’est suspendu le jour où votre projet s’est suspendu.

Cet écoulement ne figure sur aucune des pièces que vous détenez, parce qu’aucune n’a été écrite pour le suivre. Les calendriers qui le portent appartiennent aux équipes qui maintiennent votre socle et aux services extérieurs sur lesquels il s’appuie, et ils se consultent publiquement. Ils sont donc lisibles avant tout rendez-vous, à condition de savoir depuis quelle date les lire.

L’effet se découvre à la remise en marche du code, et il surprend parce qu’il ne tient pas à la qualité du travail livré. Un rattrapage de calendrier se compte en versions à remonter et en comptes à rouvrir, deux relevés qui ne disent rien de la façon dont le code a été écrit. La durée de l’arrêt et la valeur de ce qui a été écrit sont donc deux sujets distincts, qui se chiffrent séparément et qui se traitent dans cet ordre. Le second demande de trier fonction par fonction ce qui tient et ce qui repart de zéro, un travail que le calendrier laisse entier.

Un chantier dont le développement continue pendant que la relation se dégrade relève d’un autre sujet, celui d’organiser le relais avant la rupture plutôt qu’après. Ce qui suit suppose aussi que vous détenez encore le code source, l’hébergement et le nom de domaine : si un prestataire disparu vous en a privé, c’est par reprendre la main sur ces accès qu’il faut commencer. Ce qui suit traite le projet à l’arrêt au sens strict, celui où plus personne n’a touché une ligne depuis une date que vous pouvez nommer.

Trois documents datent le dernier travail effectué

Toute la suite se calcule depuis une seule date, celle du dernier travail réellement effectué sur ce développement. Appelons-la la date de gel. Elle se retrouve à trois endroits, et il vaut mieux relever les trois.

Le premier est l’historique des modifications conservé dans le dépôt de code. Chaque enregistrement y porte sa date, et le plus récent donne le jour où quelqu’un a écrit pour la dernière fois. Le deuxième est votre comptabilité, à la date de la dernière facture réglée sur ce développement. Le troisième est le dernier compte rendu de recette, celui du dernier passage où quelqu’un a ouvert les écrans livrés et noté ce qui allait et ce qui n’allait pas.

Quand ces trois dates ne coïncident pas, leur écart se lit. Une dernière facture postérieure de plusieurs mois au dernier enregistrement de code n’a rien d’anormal en soi, puisqu’une facture se règle après le travail qu’elle couvre. Ce qui se vérifie, c’est la période sur laquelle elle porte, et si cette période dépasse la date du dernier enregistrement. C’est la première question à poser à l’équipe partie. Quand la dernière recette est bien antérieure aux deux autres, une part du travail est partie sans que personne l’ouvre, et c’est cette part qui ressort en premier au redémarrage, parce qu’elle n’a jamais été confrontée à vos propres cas.

Ce même contrat mérite une seconde lecture, celle de la clause de cession des droits sur le code écrit. Une cession incomplète, une réserve de propriété ou une clause d’exclusivité au bénéfice du prestataire parti change qui a le droit de faire reprendre ce développement, avant même de discuter de calendrier ou de devis.

Ce qui expire sans que personne le décide

L’adresse à laquelle vous alliez regarder l’avancement, votre environnement de recette, tient par un certificat qui affiche le cadenas dans le navigateur. Let’s Encrypt, l’autorité de certification qui délivre ces certificats gratuitement, recommande de les renouveler tous les 60 jours, bien avant l’échéance de 90 jours déjà posée plus haut. Ce renouvellement se fait tout seul tant qu’un programme tourne pour le déclencher. Il cesse quand le serveur qui exécutait ce programme s’éteint, quand le compte qui hébergeait ce serveur se ferme, ou quand la personne qui l’avait mis en place s’en va sans le transmettre.

Let’s Encrypt envoyait jusque-là un courriel d’avertissement avant chaque expiration, et cette autorité a mis fin à ce service le 4 juin 2025. Un projet laissé sans surveillance ne reçoit donc plus cet avertissement, et son certificat expire sans que rien parte de chez l’autorité. Vous l’apprenez le jour où vous rouvrez l’adresse et où le navigateur affiche un avertissement de sécurité à la place de votre projet.

Cet écran ne renseigne en rien sur l’état du code derrière lui. Un développement complet et un développement à moitié écrit produisent le même avertissement. Un certificat expiré et un développement perdu se ressemblent donc à l’écran, et la seule façon de les distinguer est d’aller chercher le code source ailleurs que derrière cette adresse.

Une fin de support franchie pendant l’arrêt

Votre développement a été écrit sur un socle, c’est-à-dire un langage et un ensemble de briques logicielles qui l’exécutent. Chaque brique est maintenue par une équipe qui annonce à l’avance le jour où elle cessera de la corriger. Cette échéance s’appelle la fin de support, elle est inscrite au calendrier de la brique avant d’y arriver, et celui qui a écrit votre projet n’a pas la main dessus.

Node.js, l’un des socles courants pour ce type de développement, en donne la mesure. Sa documentation indique qu’une version en support long garantit le plus souvent la correction des bugs critiques pendant un total de 30 mois. Le groupe qui gère ses livraisons tient à part le tableau des échéances, où chaque fin de vie est inscrite au jour près. Node.js 18, sorti en avril 2022, y porte la date du 30 avril 2025. Node.js 20, sorti en avril 2023, y porte celle du 30 avril 2026. Un projet écrit sur Node.js 20 puis arrêté courant 2024 a donc franchi sa fin de support pendant l’arrêt, sans que personne ait rien décidé ni rien signé.

Symfony publie la même chose sous une autre forme, et sa documentation donne deux régimes. Une version standard reçoit des corrections de bugs pendant 8 mois, et des corrections de sécurité pendant 8 mois également. Une version à support long reçoit des corrections de bugs pendant 3 ans et des corrections de sécurité pendant 4 ans. Ces durées courent depuis la sortie de la version, jamais depuis le jour où votre projet a commencé. Un développement démarré sur une version standard et arrêté un an plus tard tourne donc sur une version que plus personne ne corrige. Sur une version à support long, la réponse dépend de l’âge qu’avait déjà cette version le jour où votre développement s’y est appuyé.

Ces versions se lisent sans exécuter le projet. Elles sont inscrites dans les fichiers de configuration à la racine du code source, et un développeur vous les nomme en les ouvrant. Vous pouvez demander cette lecture avant tout devis, y compris à celui qui les a choisies.

Ce que cette date change dans un devis de reprise

Un socle sorti du support impose un premier lot qui n’ajoute aucune fonction. Ce lot remonte la version jusqu’à une version encore corrigée, et il faut ensuite vérifier que ce qui était écrit fonctionne toujours dessus. Le devis de reprise le fait apparaître à part, pour une raison qui vous concerne, il ne figurait dans aucun des chiffrages que vous avez signés. Ce chantier consiste à remonter la base technique d’un développement sans toucher à ce qu’il produit.

Sa taille dépend du nombre d’échéances franchies pendant l’arrêt, et non du nombre de mois écoulés. Deux projets arrêtés la même durée n’appellent donc pas la même remise à niveau. Celui qui a été gelé quelques semaines avant une fin de support en franchit une. Celui qui s’est appuyé sur une version à support long encore jeune n’en franchit parfois aucune. C’est la part de l’écart qui s’établit avec un calendrier public et une soustraction de dates, une fois la version connue, et avant tout rendez-vous de chiffrage. Elle vous donne le nombre d’échéances à rattraper, sans vous donner le montant du rattrapage, et ce nombre suffit déjà à savoir si la question se pose.

Ce que l’arrêt n’a pas abîmé

Ce qui traverse un arrêt intact, c’est l’écrit et le décidé, le cahier des charges, les maquettes validées, les règles de calcul arbitrées avec vos équipes et les comptes rendus de recette. Ces documents disent ce que l’outil devait faire, et ils gardent leur valeur entière, parce que les arbitrages qu’ils consignent n’auront pas à être repris une seconde fois. Le code qui traduit ces arbitrages garde la sienne tant que ces arbitrages tiennent encore. Quand l’un d’eux a changé chez vous pendant l’arrêt, c’est le code correspondant qui est à reprendre, et la sixième ligne du relevé plus bas sert à repérer lesquels.

Ce constat a sa contrepartie. Ce qui n’a jamais été écrit ne l’est pas devenu pendant l’arrêt, et son absence se paie au moment de la reprise. Quand ces arbitrages ne figurent nulle part, ils vivent dans le code et dans la mémoire de gens qui sont partis, et il faut aller les y chercher. Ce travail consiste à rétablir par écrit ce que fait un outil quand plus personne ne sait l’expliquer. Son montant tient à ce que l’équipe précédente a consigné avant de partir, et il ne se connaît qu’une fois le dossier ouvert.

Un projet qui n’a jamais été ouvert à personne garde par ailleurs une marge qu’un outil déjà en service a perdue. Aucune donnée de production ne s’y trouve, aucune équipe n’a pris ses habitudes sur ses écrans, et aucun de vos clients ne les connaît. Retirer une part du périmètre prévu n’entraîne donc ni reprise de données, ni formation à refaire, ni annonce à passer. Cette marge disparaît le jour de l’ouverture.

Reprendre ne veut donc pas dire finir ce qui était prévu. Vous pouvez ouvrir en premier ce qui a déjà été vérifié en recette, et laisser dans le cahier des charges d’origine ce que personne n’a jamais ouvert, où il attendra sans rien coûter. C’est la voie la moins chère, et elle reste ouverte tant que le service n’est pas rendu à un premier utilisateur. Chaque semaine passée à compléter le périmètre d’origine est une semaine sans service rendu, quelle que soit la part déjà écrite.

Reprise ou projet neuf, deux chiffrages posés côte à côte

Deux chiffrages tranchent entre la reprise et le projet neuf, et un pourcentage d’avancement annoncé au moment de l’arrêt n’y suffit pas. Le premier, le chiffrage de reprise, additionne le reste à faire, la remise à niveau du socle et la reconstitution de ce qui n’a pas été écrit. Le second chiffre le même périmètre en repartant de zéro, avec les documents que vous détenez déjà, qui servent dans les deux cas et qui ne se rachètent pas.

Le reste à faire annoncé au moment de l’arrêt n’entre dans cette comparaison qu’une fois revérifié. Il a été établi par une équipe qui écrivait encore, sur un socle alors soutenu, et il ne portait ni la remise à niveau ni la reconstitution des écrits manquants. Reprendre ce chiffre tel quel revient à comparer un montant complet à un montant partiel, et l’écart qui en sort ne mesure alors que cette différence de périmètre.

Demandez les deux sur le même périmètre, écrit une seule fois, faute de quoi vous comparerez deux lectures du besoin plutôt que deux montants. Un écart net dans un sens ou dans l’autre tranche seul. Un écart faible rend la comparaison sensible aux hypothèses retenues de chaque côté, et il vaut alors mieux demander à les voir écrites. Quand les deux montants se rapprochent, ce qui départage n’est plus l’argent mais le délai, et la part de décisions qu’il faudrait reprendre depuis le début.

Le relevé en six lignes, trois dates et trois listes

Une page suffit pour ce relevé, qui se remplit sans exécuter le projet. Ses trois premières lignes produisent des dates, les trois dernières des listes.

La première est la date de gel, sous ses trois formes, dernier enregistrement dans l’historique du code, dernière facture réglée, dernier compte rendu de recette.

La deuxième est la version du socle, telle qu’elle est inscrite dans les fichiers de configuration. Faites-la lire par quelqu’un qui sait ouvrir le code, puis posez en face la date de fin de support publiée par son éditeur. Comparez cette date à aujourd’hui, puis à votre date de gel. Vous saurez si l’échéance a été franchie pendant l’arrêt ou si elle l’était déjà avant.

La troisième est l’état du certificat de votre environnement de recette. Ouvrez cette adresse dans un navigateur et notez laquelle des trois réponses vous obtenez. La page s’affiche, et le renouvellement tourne encore. Un avertissement de sécurité la remplace, et le certificat que le navigateur vous laisse consulter porte sa date de fin de validité : relevez-la, elle dit jusqu’à quand le dernier renouvellement réussi couvrait l’adresse, et posée à côté de votre date de gel elle situe l’arrêt du renouvellement dans les 90 jours qui la précèdent. Rien ne répond du tout, et c’est le serveur lui-même qui s’est éteint ou dont le compte s’est fermé, ce qui ne vous apprend rien sur le code et vous renvoie à la ligne suivante.

La quatrième porte sur les services extérieurs auxquels le développement est raccordé, l’envoi de courriels, l’encaissement, la cartographie, la messagerie SMS. Pour chacun, notez si le compte apparaît encore sur vos propres relevés bancaires, et à quelle date le dernier prélèvement est passé. Un prélèvement interrompu vous donne une seconde date à poser à côté de votre date de gel. Un compte dont aucun prélèvement n’apparaît chez vous a été souscrit ailleurs, ou sans frais, et dans les deux cas rien chez vous n’établit que vous en êtes le titulaire. La marche à suivre est alors celle décrite quand le prestataire ne répond plus aux relances.

La cinquième croise le dernier compte rendu de recette avec le cahier des charges d’origine. Chaque fonction prévue tombe dans l’un de deux cas, vérifiée et acceptée, ou jamais vérifiée. Ce second cas ne se subdivise pas depuis ces deux documents, puisqu’aucun des deux ne dit si la fonction a été écrite. Notez-le tel quel, et c’est la remise en marche du code, plus bas, qui séparera ce qui a été livré sans être ouvert de ce qui n’a jamais été commencé. C’est le cas qui compte, parce que c’est le seul dont vous ignorez le contenu.

La sixième liste ce qui a changé chez vous depuis la date de gel et que le cahier des charges ne connaît pas, une grille tarifaire, un mode de facturation, un circuit de validation interne. Une ligne par changement suffit, la mesure de leur effet sur le projet vient plus tard.

Lu d’un bloc, ce relevé sépare deux dépenses. Le reste à faire figurait déjà dans le chiffrage d’origine, et l’arrêt ne lui a rien ajouté ni rien retiré. L’écart, lui, s’est constitué pendant l’arrêt, il n’a jamais été chiffré par personne, et il grandit à chaque échéance franchie. Le relevé ne vous en donne pas le montant, il en donne le contenu ligne par ligne, ce qui suffit à le faire chiffrer à part.

La vérification qui précède tout chiffrage

Ces six lignes situent le projet dans le temps, et elles ne disent pas si le code redémarre. Cette réponse ne se lit dans aucun document. Elle s’obtient en sortant le code source de la machine de son auteur et en le remettant en marche ailleurs, sur un poste qui n’a jamais servi à l’écrire. Tant que cette remise en marche du code n’a pas eu lieu, tout montant annoncé pour finir le projet reste une estimation, y compris celui que vous donnerait l’équipe partie. C’est la seule ligne du relevé qui demande d’installer le projet ailleurs, et non de lire un document ou une adresse.

C’est par là que commence une reprise de développement chiffrée jusqu’à la mise en service, et le chiffrage vient ensuite. Quand le dossier est volumineux, ou quand plus personne ne sait ce qu’il contient, la même vérification s’élargit et l’examen du code, des données et de l’hébergement se commande séparément, sans engager la reprise elle-même.

Votre relevé, lui, garde son utilité devant n’importe quel interlocuteur, parce qu’il déplace la question posée. Elle ne porte plus sur ce qu’il reste à écrire, elle porte sur ce qu’il faut rattraper avant de recommencer à écrire, et sur les échéances qui tomberont si la décision attend encore.

Sources

Frequently Asked Questions, Let’s Encrypt, consulté le 9 septembre 2026, https://letsencrypt.org/docs/faq/

Expiration Notification Service Has Ended, Let’s Encrypt, 26 juin 2025, https://letsencrypt.org/2025/06/26/expiration-notification-service-has-ended

Previous Releases, Node.js, consulté le 9 septembre 2026, https://nodejs.org/en/about/previous-releases

Release Schedule, Node.js Release Working Group, consulté le 9 septembre 2026, https://github.com/nodejs/Release

The Release Process, documentation Symfony, consulté le 9 septembre 2026, https://symfony.com/doc/current/contributing/community/releases.html