Le développeur ne répond plus. Il est peut-être passé à autre chose, la relation s'est peut-être mal terminée, ou il s'est simplement tu. Le logiciel tourne toujours, et c'est la partie qui fait attendre les gens plus longtemps qu'ils ne le devraient - cela marche, donc ce n'est pas encore une urgence.
C'est une urgence. Chaque semaine d'attente, quelque chose que vous ne saviez pas être au nom de quelqu'un d'autre expire.
Vérifiez ces cinq choses aujourd'hui
Pas la semaine prochaine. Chacune peut être récupérée tant que le compte est actif, et devient un problème juridique coûteux dès qu'il expire.
- Le bureau d'enregistrement du domaine. Cherchez votre domaine sur un service WHOIS. Si le titulaire n'est ni vous ni votre entreprise, vous ne contrôlez pas votre propre adresse. C'est celle qui coule des entreprises.
- Le DNS. Souvent chez un prestataire différent du bureau d'enregistrement. Qui contrôle le DNS contrôle où vont vos e-mails.
- Le serveur ou le compte d'hébergement. Sur quelle carte est-il prélevé ? Une carte expirée sur le compte de quelqu'un d'autre supprime votre site avec un e-mail automatique que personne ne lit.
- Le dépôt de code. GitHub, GitLab, Bitbucket. Si vous ne l'avez jamais vu, partez du principe que vous ne l'avez pas.
- Les comptes tiers. Le prestataire de paiement, le service de facturation, la passerelle SMS, l'analytique. Chacun est un accès distinct et chacun peut être résilié sans vous.
Notez ce que vous trouvez. Cette liste est l'état réel de ce que vous possédez, et il est en général pire que ce que le contrat laisse croire.
« Le code nous appartient » n'est pas la même chose que posséder le système
La plupart des contrats cèdent les droits d'auteur sur le code source, et la plupart des clients lisent cela comme une propriété. C'est moins que ce que cela laisse entendre.
Posséder le code veut dire que vous pouvez légalement l'utiliser et le modifier. Cela ne veut pas dire que vous en avez une copie, que quelqu'un sait le faire tourner, que les comptes avec lesquels il communique sont les vôtres, ni que la personne qui sait pourquoi il a été construit ainsi est tenue de l'expliquer. J'ai repris des systèmes où le client détenait des droits parfaitement valides sur un logiciel qu'il ne pouvait pas déployer, sur un serveur auquel il n'avait pas accès, avec des clés d'API enregistrées sur une adresse e-mail personnelle d'une entreprise qui n'existait plus.
La propriété est une liste de contrôle, pas une clause.
Ce que l'on peut généralement sauver
Plus de choses qu'on ne le craint. Un code qui vous est étranger n'est pas pour autant un mauvais code, et le logiciel hérité a une réputation qu'il ne mérite pas toujours - un système écrit par quelqu'un d'autre aura toujours l'air pire que le vôtre, parce que vous n'en voyez pas le raisonnement.
Ce qui tranche vraiment est plus restreint que la qualité du code :
- Les données sont-elles intactes et exportables ? C'est la seule partie irremplaçable. Le code se réécrit en quelques semaines ; cinq ans de fiches clients ne se reconstituent pas du tout.
- Le système se déploie-t-il encore ? Un système que personne ne peut reconstruire à partir des sources est un système qui tourne sur une machine que vous ne devez jamais redémarrer.
- Les dépendances sont-elles encore maintenues ? Un framework en retard de trois versions majeures est un budget, pas un blocage.
- Les secrets sont-ils récupérables ? Les clés se réémettent. Ce sont les comptes qui les détiennent qui posent problème.
Remarquez qu'aucune de ces questions n'est « le code est-il élégant ». J'ai stabilisé des systèmes franchement laids en une semaine parce que les données étaient propres et que le déploiement fonctionnait, et j'ai recommandé de remplacer des systèmes bien propres où ni l'un ni l'autre n'était vrai.
La réponse honnête est souvent « moins que vous ne le pensez »
Les gens arrivent en s'attendant à s'entendre dire qu'il faut tout reconstruire, en partie parce que c'est ce que leur a dit le dernier à avoir chiffré. Parfois c'est vrai. Le plus souvent le système est sain et ce qui a lâché, c'est tout ce qu'il y avait autour : personne ne savait déployer, les sauvegardes n'ont jamais été testées, et une seule personne détenait tous les comptes.
C'est une semaine de travail et une passation, pas une réécriture. Je préfère vous dire cela et vendre une semaine de travail plutôt que de vous vendre six mois dont vous n'aviez pas besoin - en partie parce que c'est vrai, et en partie parce que le client à qui on a dit la vérité est celui qui revient.
Comment ne plus jamais en arriver là
Quel que soit le prestataire que vous engagez ensuite, exigez ceci avant que la première ligne ne soit écrite, et non à la fin : chaque compte est créé à votre nom, par vous, et le développeur y est ajouté. Pas transféré à la livraison. Créé à votre nom dès le premier jour.
Cela ne coûte rien, cela prend un après-midi, et c'est toute la différence entre un changement de prestataire et une crise. Si un développeur y résiste, vous avez appris quelque chose de précieux tôt, quand cela coûte encore peu.
Le reste du standard de passation - documentation, tests, un déploiement que votre propre équipe peut lancer - est sur ma page services, et la raison pour laquelle j'y tiens autant est dans la note sur qui utilise vraiment votre logiciel.