Recevoir le code source de son logiciel change une chose essentielle : vous cessez d'en être l'utilisateur pour en devenir le propriétaire. Vous pouvez le faire corriger, adapter ou étendre par l'équipe de votre choix, l'installer où vous le décidez et le conserver quoi qu'il arrive à celui qui l'a écrit. Cette liberté n'est toutefois réelle que si le code est remis complet, documenté et accompagné des droits correspondants.
Qu'est-ce que le code source, en termes simples ?
Un logiciel existe sous deux formes. La première est celle que vous utilisez : des écrans, des boutons, des rapports. La seconde est le texte rédigé par les développeurs, qui décrit dans un langage de programmation tout ce que le logiciel doit faire. Ce texte est le code source. Il est au logiciel ce que les plans sont à un bâtiment.
On peut occuper un bâtiment sans en détenir les plans. Le jour où il faut déplacer une cloison, ajouter un étage ou réparer une canalisation encastrée, tout se complique. Il en va de même pour un logiciel : tant que tout fonctionne et que rien ne change, l'absence du code ne se remarque pas. Or une organisation change en permanence, et son outil doit suivre.
Que permet concrètement la remise du code source ?
- Faire évoluer l'outil. Une nouvelle règle, un nouveau service, une nouvelle obligation réglementaire : la modification est possible sans dépendre de la bonne volonté d'un éditeur.
- Changer de prestataire. Si la relation se dégrade ou si le prestataire cesse son activité, une autre équipe peut reprendre le travail.
- Internaliser. Une organisation qui se dote d'une équipe technique peut reprendre progressivement la maintenance.
- Faire contrôler. Un tiers de confiance peut examiner le code pour vérifier la sécurité ou la conformité.
- Choisir son hébergement. Vous pouvez installer la solution sur l'infrastructure de votre choix et la déplacer.
- Protéger la continuité. Un service public ou une activité critique ne peut pas dépendre de la survie d'un fournisseur.
Cette liste n'épuise pas le sujet. Elle illustre un principe : chaque décision future concernant votre outil reste entre vos mains.
Un cas typique : le champ qu'on ne pouvait plus modifier
Une organisation fait développer une application de gestion de ses adhérents. Le projet se passe bien, l'outil est utilisé pendant plusieurs années. Puis une évolution réglementaire impose d'ajouter une information sur chaque fiche et de modifier un calcul. La demande est modeste.
Le prestataire d'origine n'existe plus. L'organisation découvre alors qu'elle ne détient que les identifiants d'accès à l'application. Le code est resté sur les machines de l'ancien prestataire, l'hébergement était à son nom, et le contrat ne disait rien de la propriété. Les équipes ont tenu un tableur en parallèle pendant des mois pour suivre l'information manquante, avant de devoir faire reconstruire l'outil entièrement. Rien de tout cela n'était lié à la qualité du logiciel. Tout tenait à une clause absente.
Le code source suffit-il à lui seul ?
Non, et c'est le point le plus mal compris. Un dossier de fichiers remis sur une clé le dernier jour ne garantit rien. Pour qu'une autre équipe puisse reprendre le travail, plusieurs éléments doivent accompagner le code.
| Élément remis | À quoi il sert |
|---|---|
| Dépôt de code complet avec son historique | Comprendre ce qui a été fait, quand et pourquoi |
| Documentation technique | Permettre à un nouveau développeur de s'y retrouver |
| Schéma de la base de données | Savoir comment vos données sont organisées |
| Procédure d'installation et de déploiement | Réinstaller la solution ailleurs sans son auteur |
| Liste des composants tiers et de leurs licences | Vérifier que rien n'impose de contrainte cachée |
| Accès d'administration et sauvegardes | Garder la main sur l'exploitation et sur les données |
La lisibilité du code compte également. Un code rédigé avec soin, organisé et commenté se reprend. Un code confus peut être juridiquement à vous et pratiquement inutilisable. C'est une raison de plus de s'intéresser à la manière dont travaille le prestataire, et pas seulement à ce qu'il promet de remettre.
Que faut-il vérifier dans le contrat ?
La propriété se décide avant le premier jour du projet. Trois points méritent une lecture attentive. Le premier est la cession des droits : le contrat doit prévoir que les droits sur le logiciel développé pour vous vous sont transférés, et pas seulement qu'une copie du code vous sera remise. Le deuxième est la remise elle-même : à quel moment, sous quelle forme, avec quels documents. Le troisième concerne les données : elles doivent pouvoir être exportées dans un format exploitable, à tout moment.
Faites relire ces clauses par votre conseil juridique, car le droit applicable varie selon les pays. Pour comprendre les notions en jeu, notre article qui est propriétaire du logiciel et du code source détaille les situations les plus courantes.
Propriété du code, des données et de l'hébergement : un même sujet
Détenir le code sans maîtriser l'endroit où tournent l'application et les données laisse la moitié du chemin à parcourir. Les trois vont ensemble : le logiciel vous appartient, les données sont les vôtres et vous décidez de l'endroit où la solution est hébergée. C'est cet ensemble qui constitue une véritable maîtrise de votre outil.
Chez Linking Development, la règle est posée dès le départ : la solution, son code source et ses données appartiennent au client, qui choisit aussi le nom de son outil et son hébergement. Nous constatons que cette clarté facilite la relation : un client libre de partir reste parce que le travail lui convient.
Pour voir comment cette approche se traduit dans des projets concrets, consultez nos solutions.