Skip to content
Algori Systems

Ce que vous possédez réellement à la fin du projet

Le domaine, le code, l'hébergement, les comptes et les données. Lesquels doivent être à votre nom, et le test unique qui vous dit s'ils le sont.

Un écran d'ordinateur portable rempli de code source, photographié dans une pièce sombre.

Il existe une question que presque personne ne pose avant de signer, et elle détermine la maîtrise que vous aurez pendant toute la vie de ce que vous achetez. Quand ce sera terminé, qu'est-ce que je possède ?

Elle compte surtout au pire moment. Si la relation se termine mal, si le studio ferme, ou si vous voulez simplement travailler avec quelqu'un d'autre, la réponse détermine si c'est un désagrément ou une catastrophe.

Le domaine est celui qui ruine les gens

Votre nom de domaine doit être enregistré dans un compte qui vous appartient, avec votre adresse électronique, payé par votre carte.

C'est le piège le plus courant du métier et il n'est généralement pas malveillant. Un studio enregistre le domaine pendant la mise en place parce que c'est plus rapide que d'attendre que le client le fasse, tout le monde passe au projet, et personne n'y repense. Puis deux ans plus tard le client veut partir et découvre que l'adresse que ses clients connaissent, celle qui figure sur sa camionnette, ses cartes de visite et chaque facture qu'il a jamais envoyée, est juridiquement la propriété de quelqu'un d'autre.

Un studio coopératif la transfère en une après-midi. Un studio peu coopératif ou injoignable ne vous laisse presque aucune option, car un domaine n'est pas une chose que l'on peut reconstruire. Tout le reste de cette page peut être recréé avec du temps et de l'argent. Votre domaine, non.

Vérifiez-le aujourd'hui, quel que soit celui qui a construit votre site. Connectez-vous au bureau d'enregistrement. Si vous ne pouvez pas, vous avez la réponse.

Le code

Pour du développement sur mesure, vous devez posséder le code source purement et simplement, et le contrat doit le dire en toutes lettres plutôt que de le laisser sous-entendre.

Deux distinctions méritent d'être comprises. Le code source est ce qu'un développeur modifie. Le code déployé est ce que le serveur exécute, ce qui pour beaucoup de piles est une version compilée ou empaquetée, techniquement présente mais pratiquement inutilisable pour apporter des modifications. Recevoir la seconde en s'entendant dire que l'on possède le code n'est pas la même chose.

L'autre distinction sépare ce qui a été construit pour vous de ce avec quoi cela a été construit. Les frameworks, les bibliothèques et les composants open source ne sont pas à vous et n'ont pas besoin de l'être ; ils sont librement mis à disposition de tout le monde, y compris de celui que vous recruterez ensuite. L'important est que la partie écrite spécifiquement pour votre projet vous appartienne, sans restriction sur qui a le droit de la modifier plus tard.

Si un studio emploie un framework maison propriétaire ou un constructeur de pages sous licence par site, demandez directement ce qu'il advient de votre site si vous cessez de travailler avec lui. Il existe des réponses honnêtes à cette question. Il existe aussi des studios dont tout le modèle de fidélisation repose sur le fait que la réponse est mauvaise.

Le compte d'hébergement

Même principe que le domaine, avec un enjeu légèrement moindre.

Si votre site est hébergé sous le compte du studio, vous ne pouvez pas le déplacer, vous ne voyez pas la facture, et si leur compte a un problème votre site a un problème. Dans l'idéal l'hébergement est à votre nom et vous accordez un accès. Cela dit, c'est réellement négociable : l'hébergement inclus est un service normal et légitime, et pour une entreprise sans personne de technique ce peut être exactement le bon arrangement. Cela ne devient un problème que lorsque personne ne vous l'a dit.

Nous hébergeons des projets sur notre propre infrastructure dans le cadre d'un forfait de suivi, et nous pensons que c'est une bonne affaire pour le bon client. Cela ne change rien à qui possède le domaine ou le code, et cela ne devrait rien y changer chez personne d'autre non plus.

Les comptes qui gravitent autour

La liste que l'on oublie. Les statistiques, le prestataire de paiement, le service d'emailing, les outils pour webmasters, les profils sociaux créés au lancement, le certificat SSL s'il n'est pas automatique, et tout service tiers dont le site dépend.

Chacun d'eux doit se trouver dans un compte que vous contrôlez, avec votre adresse de récupération. Un accès accordé au studio, pas une propriété détenue par le studio. C'est la même correction dans chaque cas et elle prend quelques minutes à la mise en place, ce qui est précisément pourquoi il vaut la peine d'y tenir à la mise en place plutôt que de démêler cela plus tard.

Les données

Vos fiches clients, commandes, demandes, réservations et votre liste de diffusion vous appartiennent et, dans un sens important, appartiennent aux personnes qu'elles décrivent.

Vous devez pouvoir tout exporter dans un format qu'un autre outil sait lire. Demandez-le avant de signer, pas après. Un système dont vous ne pouvez pas sortir vos données est un système que vous ne pourrez jamais quitter, et c'est parfois une conception délibérée plutôt qu'un oubli.

Le test

Oubliez la formulation du contrat et posez une seule question. Si vous engagiez un autre développeur demain, de quoi auriez-vous besoin de notre part, et pourriez-vous l'obtenir sans notre coopération ?

Si la réponse honnête est que vous pourriez remettre à quelqu'un les identifiants du domaine, les accès à l'hébergement, le code et un export de la base de données, et qu'il pourrait continuer, alors vous possédez votre projet. Si la réponse suppose que nous soyons d'accord, vous ne le possédez pas, quoi qu'en dise la facture.

Pourquoi nous organisons notre travail ainsi

Nos projets à prix fixe sont exactement cela : vous le possédez et vous l'exploitez, sans frais récurrents, les travaux ultérieurs étant chiffrés quand vous les voulez. Notre forfait de suivi nous garde à héberger et entretenir la chose, mensuellement, aussi longtemps qu'elle tourne.

Si nous séparons selon qui exploite plutôt que selon la façon de payer, c'est que la seconde formulation encourage discrètement le piège décrit plus haut. Quand le revenu récurrent dépend de l'incapacité du client à partir, l'incitation est de rendre le départ difficile. Quand il dépend d'un entretien qu'il faudrait autrement assurer soi-même, l'incitation est de mériter d'être gardé.

Vous devez rester propriétaire de votre domaine et de votre code dans les deux cas. Si un studio vous dit un jour le contraire, c'est toute la réponse à son sujet.