Le code source à votre nom : pourquoi c'est non négociable

Quand vous faites développer un logiciel, vous payez pour un outil. Mais l'outil, ce n'est pas l'écran que vos équipes utilisent : c'est le code source qui le fait fonctionner. Sans lui, vous ne pouvez ni changer de prestataire, ni faire corriger un problème par quelqu'un d'autre, ni même savoir ce que fait exactement votre logiciel. Chez Glowsoft, la remise du code source et de sa documentation au client fait partie de chaque projet. Voici pourquoi nous y tenons, et ce que vous devez vérifier, avec nous ou avec n'importe qui d'autre.

Le problème : un logiciel que vous utilisez sans le posséder

Nous rencontrons régulièrement des dirigeants dans la même situation. Un outil a été développé il y a quelques années. Il marche, plus ou moins. Le prestataire d'origine a changé de priorités, augmenté ses tarifs, ou disparu. Et au moment de faire évoluer l'outil, la question tombe : « Où est le code ? »

Les réponses sont rarement bonnes :

• le code est sur les serveurs du prestataire, et lui seul y a accès ;
• le contrat parle d'une « licence d'utilisation », pas d'une cession de droits ;
• le code existe, mais personne ne sait le déployer, faute de documentation ;
• les accès à l'hébergement, au nom de domaine ou aux comptes des magasins d'applications sont au nom du prestataire.

Dans tous ces cas, l'entreprise dépend d'un seul acteur pour un outil qui fait tourner une partie de son activité. Ce n'est pas une question de confiance envers une personne : c'est un risque d'entreprise, au même titre qu'un fournisseur unique pour une pièce critique.

Ce que « remettre le code source » veut dire chez nous

Une archive envoyée par e-mail le jour de la livraison ne suffit pas. Pour que le code vous serve vraiment, il faut quatre choses :

1. Le code complet, à jour, dans un dépôt auquel vous avez accès. Pas une copie figée : l'historique des modifications, qui permet de comprendre pourquoi telle ligne a changé.
2. La documentation. Comment installer le logiciel, comment le déployer, comment il est organisé, quelles sont les dépendances externes. C'est ce qui permet à un autre développeur de reprendre le projet.
3. Les accès à votre nom. Nom de domaine, hébergement, comptes Apple et Google pour une application mobile, services tiers (envoi d'e-mails, paiement) : au nom de votre entreprise, avec nous comme utilisateurs autorisés, et non l'inverse.
4. Les droits écrits dans le contrat. En droit français, les droits patrimoniaux sur un logiciel développé par un prestataire ne vous sont transmis que si le contrat le prévoit. La cession doit être explicite.

Ce dernier point mérite une précision honnête : un logiciel s'appuie toujours sur des briques open source et parfois sur des services tiers, qui gardent leurs propres licences. Ce qui vous est cédé, c'est ce qui a été écrit pour vous. Une bonne documentation liste le reste.

« Mais alors, vous risquez de perdre le client ? »

On nous pose souvent la question. Oui, un client qui a son code peut partir. C'est justement le but. Nous préférons que nos clients restent parce que le travail est bon et la maintenance réactive, pas parce qu'ils sont coincés. C'est aussi ce qui nous oblige à écrire un code propre et documenté : nous savons qu'il pourra être relu.

Il y a un autre bénéfice, moins visible. Un code qui vous appartient peut être audité. Si votre client grand compte, votre assureur ou votre direction informatique demande comment le logiciel traite les données, vous pouvez le montrer, au lieu de transmettre une promesse.

Les questions à poser avant de signer

Que vous travailliez avec nous ou avec un autre prestataire, voici la liste que nous recommandons d'avoir sous les yeux au moment du devis :

• Le contrat prévoit-il une cession des droits sur le code développé pour nous, et pas seulement une licence ?
• Aurons-nous accès au dépôt de code pendant le projet, et pas seulement à la fin ?
• Quelle documentation sera livrée, et sera-t-elle tenue à jour pendant la maintenance ?
• Les comptes d'hébergement, de domaine et de publication seront-ils à notre nom ?
• Quelles briques tierces sont utilisées, sous quelle licence, et avec quels coûts récurrents éventuels ?
• Que se passe-t-il si nous voulons confier la maintenance à quelqu'un d'autre ? Combien de temps pour transmettre ?

Un prestataire sérieux répond à ces questions sans hésiter. S'il hésite, vous avez votre réponse.

Comment ça s'inscrit dans notre méthode

La remise du code n'est pas une étape isolée à la fin. Elle découle de la façon dont nous travaillons : un prix fixé avant de coder, une version testable toutes les deux semaines, des tests avec vos utilisateurs, puis la livraison et la formation. À chaque étape, le code avance dans un dépôt que vous pouvez consulter. Le jour de la livraison, il n'y a rien à « récupérer » : tout est déjà chez vous.

Si vous avez un projet de logiciel, ou un outil existant dont vous ne maîtrisez pas le code, parlons-en. Vous pouvez aussi parcourir nos réalisations. Le premier rendez-vous de 30 minutes est gratuit.