Juin, fin de projet. Un transporteur régional reçoit la plateforme de planification de tournées commandée huit mois plus tôt à une ESN. Trois semaines de tests plus tard, le tableur partagé compte cent quarante anomalies, sans aucune hiérarchie entre un bouton mal aligné et un calcul d’itinéraire faux. L’ESN considère le logiciel comme livré, puisque le client l’utilise déjà sur un dépôt pilote. Le client refuse de payer le dernier jalon. Le prestataire suspend la maintenance. Le cas est inventé ; vous en reconnaîtrez sans doute plusieurs épisodes.
Comment la recette a dérapé, et ce qui aurait dû la cadrer
Le premier problème se situe en amont. Les spécifications parlaient d’un « export des tournées vers l’ERP ». L’ESN a livré un fichier CSV, l’équipe métier attendait une synchronisation en temps réel. Sans référentiel précis et validé, chacun teste contre sa propre idée du produit, et la recette tourne à la négociation.
Le contrat doit donc renvoyer à un cahier des charges ou à des spécifications datées et validées, fixer la durée de la période de test et classer les anomalies : bloquantes, majeures, mineures. C’est ce classement qui permet d’écrire, par exemple, que le logiciel est recevable avec des anomalies mineures, mais pas avec une seule anomalie bloquante.
Décrivez ensuite la procédure : procès-verbal de recette avec ou sans réserves, délai de correction des anomalies réservées, nouvelle vérification, puis réception définitive. Reste le point qui a fait basculer le transporteur. Beaucoup de contrats prévoient une recette tacite si le client ne se manifeste pas dans un délai donné ou s’il met le logiciel en production. Côté client, écartez-la ou encadrez-la, en précisant par exemple qu’un pilote sur un site ne vaut pas mise en production. Côté prestataire, assurez-vous au contraire qu’elle figure au contrat.
À qui appartient le code que vous avez payé ?
Le transporteur s’en croyait propriétaire. Or un code écrit par un prestataire extérieur ne devient pas la propriété du client du seul fait qu’il a été payé. La règle qui attribue à l’employeur les droits sur les logiciels créés par ses salariés dans l’exercice de leurs fonctions (article L113-9 du Code de la propriété intellectuelle) ne joue ni pour un développeur indépendant ni pour une société prestataire. Il faut une cession écrite.
L’article L131-3 du même code sert de référence pour la rédiger : chaque droit cédé fait l’objet d’une mention distincte, et le domaine d’exploitation est délimité quant à son étendue et à sa destination, quant au lieu et quant à la durée. Pour un logiciel, la cession vise en général la reproduction, l’adaptation, la modification, la traduction et la mise sur le marché.
Ne réclamez pas pour autant la cession de tout le dépôt. Un projet mêle trois catégories de code : le développement spécifique, qui peut être cédé ; les briques préexistantes du prestataire, frameworks maison ou modules réutilisés, qui font généralement l’objet d’une simple licence ; les composants open source, soumis à leurs propres licences, dont certaines imposent des obligations en cas de redistribution. Exigez une annexe qui liste ces composants. Elle vous servira lors d’un audit, d’une levée de fonds ou d’une cession future.
Maintenance : des délais chiffrés plutôt qu’une promesse de réactivité
Quand l’ESN a suspendu la maintenance, le transporteur a relu son contrat : « intervention dans les meilleurs délais ». Formule inutilisable le jour où la production s’arrête. Séparez la garantie, c’est-à-dire la correction sans supplément des anomalies signalées pendant une période suivant la réception, la maintenance corrective, la maintenance évolutive et les mises à jour de sécurité des dépendances. Ce sont quatre engagements distincts ; les confondre, c’est découvrir au premier incident qu’aucun ne couvre votre cas.
Pour chaque niveau de gravité, fixez un délai de prise en compte et un délai de correction ou de contournement, en précisant les jours et horaires couverts. Une anomalie bloquante signalée un vendredi à 18 heures doit trouver sa réponse dans le contrat, pas dans la bonne volonté de l’équipe d’astreinte. Les modèles proposés par l’une ou l’autre partie sont rarement neutres sur ces engagements de service. Pour une relecture, le cabinet Desrumaux Avocats présente son accompagnement en droit des contrats sur https://www.avocat-desrumaux.fr/avocat-droit-des-contrats-bordeaux/.
La sortie se prépare le jour de l’entrée
Le transporteur a fini par vouloir changer de prestataire, et découvert que le dépôt Git, l’environnement cloud et le nom de domaine de l’application étaient tous au nom de l’ESN. Récupérer le code ne suffit pas. La clause de réversibilité précise ce qui est remis, dans quel délai et à quel coût :
- le code source à jour et l’historique du dépôt ;
- la documentation technique et les procédures de déploiement ;
- les données, dans un format exploitable ;
- les accès aux environnements, aux comptes cloud, aux noms de domaine et aux identifiants d’API ;
- une assistance au transfert vers le nouveau prestataire, sur une durée définie.
Le plus simple reste d’ouvrir dès le départ le dépôt de code et les comptes d’hébergement au nom du client, le prestataire y disposant d’accès délégués. Dix minutes au lancement du projet, contre des semaines de discussion au moment du départ.
Le jour où la DPO demande le contrat de sous-traitance
Dernier épisode : la déléguée à la protection des données du transporteur réclame le contrat qui encadre l’accès de l’ESN aux données des chauffeurs, présentes en production. Il n’existe pas. Or dès que le prestataire accède à des données personnelles, parce qu’il héberge l’application, intervient sur la base de production ou teste avec des données réelles, il agit en principe comme sous-traitant au sens du RGPD. L’article 28 du RGPD impose alors un contrat qui définit l’objet et la durée du traitement, sa nature et sa finalité, le type de données et les catégories de personnes concernées.
Le prestataire s’y engage notamment à ne traiter les données que sur instruction documentée du client, à garantir leur confidentialité, à mettre en œuvre les mesures de sécurité requises et à ne recourir à un autre sous-traitant qu’avec l’autorisation du client. Il doit aussi l’aider à répondre aux demandes des personnes concernées, supprimer ou restituer les données en fin de prestation, et fournir les informations nécessaires pour démontrer sa conformité et permettre les audits. Prévoyez au passage des jeux de données anonymisés pour les tests : autant de données réelles qui ne circulent pas.
Si votre projet avance en sprints, ne laissez personne vous expliquer que l’agilité dispense de spécifications. Faites valider par écrit le périmètre de chaque sprint et archivez ces validations avec le contrat. Elles deviendront votre référentiel de recette, et c’est précisément ce qui manquait au transporteur en juin.
