Et si vous disparaissez ?
La question que pose toute organisation qui confie un outil de production à une petite structure. Elle est légitime, et elle a une réponse simple : ne dépendez pas de nous pour continuer.
Le doute n'est pas sur la compétence
Si vous nous avez laissés venir présenter une solution, c'est que le besoin existe et que le travail vous paraît sérieux. La question qui reste n'est pas « savez-vous faire », c'est « que se passe-t-il si vous n'êtes plus là ».
Beaucoup de prestataires y répondent par des dispositifs qui s'activent le jour où ça tourne mal. Nous préférons l'inverse : que rien n'ait à s'activer, parce que vous détenez déjà tout ce qu'il faut pour continuer sans nous.
1. L'hébergement peut être à votre nom
Nous proposons systématiquement que le serveur soit ouvert chez un hébergeur français, à votre nom, avec votre moyen de paiement. Vous en êtes alors propriétaire, nous n'y sommes qu'invités, et vous pouvez nous en retirer l'accès d'un geste — sans nous le demander.
En pratique, la plupart des entreprises préfèrent que nous nous en chargions : c'est une contrainte de moins. Mais l'option existe, elle est écrite dans la proposition, et c'est ce qui compte. Les attestations de l'hébergeur — localisation des données, certifications, conformité au RGPD — vous sont remises avec la proposition, pas cherchées après coup.
2. Le code source vous est remis au fil du projet
Pas à la livraison, pas sur demande : en continu. Le dépôt de code peut être le vôtre dès le premier jour, chez l'hébergeur de votre choix, et nous y travaillons comme un prestataire travaille dans vos locaux.
À tout moment, vous avez donc l'intégralité de ce qui a été écrit, avec son historique. Il n'y a rien à déclencher, rien à réclamer, et aucun tiers à mettre dans la boucle pour l'obtenir.
3. Ce qui est livré est fait pour être repris
Un code que personne d'autre ne peut reprendre n'est pas livré, il est prêté. Nous livrons donc avec : la procédure d'installation depuis une machine vierge, les variables d'environnement et leur rôle, la façon dont on sauvegarde et — ce que presque personne ne documente — la façon dont on restaure.
Le critère que nous nous appliquons est simple : une développeuse ou un développeur qui ne connaît pas le projet doit pouvoir le remettre en marche à partir du dépôt seul. Si ce n'est pas vrai, la documentation n'est pas finie.
Ce que cela change concrètement
Vous ne dépendez de nous que pour ce qui reste à faire, jamais pour ce qui est déjà fait. Le serveur est à vous, le code est chez vous, la procédure de reprise est écrite.
C'est moins spectaculaire qu'un dispositif juridique, et c'est plus solide : un mécanisme de secours doit être déclenché, prouvé, parfois plaidé. Un dépôt de code que vous détenez déjà ne se déclenche pas — il est là.
Ce qu'il faut savoir
- Détenir le code ne signifie pas pouvoir le reprendre du jour au lendemain : il faut quelqu'un pour le lire. Nous documentons pour réduire ce délai, pas pour prétendre qu'il est nul.
- L'hébergement à votre nom vous donne le contrôle, et avec lui la responsabilité de l'accès : personne ne peut vous le rendre si vous le perdez.
- Nous sommes une petite structure et nous ne le cachons pas. Si votre organisation exige des engagements de continuité formels, ils se traitent dans le contrat — parlons-en avant la proposition, pas après.
- Pour un projet de petite taille, une partie de cet appareillage est disproportionnée. Nous vous le dirons plutôt que de vous le facturer.
Votre direction juridique a des exigences précises ?
Transmettez-les. Les engagements de continuité se rédigent dans le contrat, pas sur une page web — et il vaut mieux en discuter avant la proposition qu'après.
Réponse sous 48 heures ouvrées · Sans engagement · Échange confidentiel