Par Justin Rialland, fondateur d’Anthera
Reprendre un projet digital laissé en plan
Un site à moitié fait, un logiciel abandonné par son prestataire, un chantier qui traîne depuis un an. Comment décider entre reprendre et repartir, sans se laisser guider par le regret de ce qui a été payé.
Beaucoup de projets ne se terminent pas. Le prestataire a disparu, l'interlocuteur interne est parti, le budget s'est épuisé avant la fin, ou le besoin a changé en cours de route.
La question qui se pose alors est toujours la même : est-ce qu'on reprend ce qui existe, ou est-ce qu'on repart ?
Le piège du coût déjà payé
Le premier réflexe est de vouloir sauver l'investissement. C'est humain, et c'est un mauvais critère : ce qui a été dépensé est dépensé, que l'on reprenne ou non.
La seule question valable est tournée vers l'avant : à partir d'aujourd'hui, quel chemin coûte le moins cher pour arriver au résultat ? Un projet à moitié fait peut très bien coûter plus cher à finir qu'à refaire.
Les quatre choses à regarder avant de décider
L'accès. Avez vous le code, les identifiants d'hébergement, le nom de domaine, la base de données ? Sans eux, la question de la reprise ne se pose même pas, et récupérer ces accès est la première tâche, parfois la plus longue.
La lisibilité du code. Un développeur extérieur doit pouvoir le lire. S'il faut une semaine pour comprendre comment une page se construit, chaque évolution future coûtera ce tarif là.
Les dépendances. Un projet bâti sur des bibliothèques abandonnées ou des versions obsolètes porte une dette qui se paiera tôt ou tard, souvent au premier problème de sécurité.
Les données. C'est le seul élément vraiment irremplaçable. Du code se réécrit, des données clients accumulées pendant trois ans, non.
La règle qui décide dans la plupart des cas
Si les données sont récupérables et que le code est illisible, il est presque toujours moins cher de repartir en reprenant les données.
Si le code est sain mais inachevé, la reprise a du sens, à condition d'avoir pu le lire avant de s'engager.
Entre les deux, le temps passé à comprendre l'existant est un investissement qu'il faut chiffrer explicitement, et pas espérer absorber.
L'audit préalable, qui n'est pas une formalité
Avant de s'engager sur une reprise, un prestataire sérieux demande à regarder le code et l'infrastructure. Quelques heures, facturées ou non, mais réelles.
Celui qui s'engage sur un périmètre et un prix sans avoir regardé prend un risque qu'il vous repassera ensuite, sous forme d'avenants. Et celui qui refuse de regarder avant de dire « il faut tout refaire » ne vous dit rien d'utile non plus.
Ce qu'il faut mettre en place pour que ça ne se reproduise pas
Trois choses, dès le nouveau départ.
Le dépôt de code sur un compte qui vous appartient, pas sur celui du prestataire. L'hébergement et le domaine à votre nom, avec les accès en votre possession. Et une documentation minimale qui dit où sont les choses et comment on les met en ligne.
Ces trois points coûtent très peu quand ils sont posés au début, et ils déterminent entièrement votre liberté le jour où vous changez d'interlocuteur.
Notre article sur à qui appartient le code détaille ce qu'il faut écrire au contrat, et celui sur la refonte de site aborde le cas d'un site qui fonctionne mais ne sert plus.