Contrat de développement logiciel offshore : les 12 clauses qui évitent de perdre votre code

Un contrat de développement logiciel offshore ne sert pas seulement à fixer un TJM ou une date de livraison. Il doit garantir qu’au premier désaccord vous gardez le code, les accès, les données et la capacité de faire reprendre le produit. À 180 € par jour, un sprint de dix jours représente 1 800 € ; sans critères de recette ni dépôt sous votre contrôle, l’économie affichée peut se transformer en plusieurs semaines de reprise.

Ce que le contrat doit réellement protéger

Un dirigeant pense souvent acheter du temps de développement. En pratique, il confie quatre actifs : son produit, sa connaissance métier, ses données et sa capacité à continuer sans le prestataire. Le contrat doit donc organiser le travail quotidien, pas seulement le conflit final.

Le premier test est simple : qui contrôle le dépôt Git, les environnements cloud et les comptes tiers ? Le client doit créer l’organisation GitHub ou GitLab, inviter l’équipe et conserver les droits administrateur. La même logique vaut pour Vercel, AWS, Supabase, Neon, Stripe, les noms de domaine et les outils d’analyse. Une clause de propriété intellectuelle ne vous aide pas immédiatement si le seul compte capable de déployer appartient au prestataire.

Le deuxième test concerne la connaissance. Sur un produit qui évoluera pendant plusieurs années, le code seul ne suffit pas. Il faut aussi récupérer les décisions d’architecture, les procédures de déploiement, les schémas de données, les dépendances, les licences open source et la liste des secrets à recréer. La documentation est un livrable contractuel, avec des critères de recette, pas une faveur réalisée à la fin lorsque le budget est épuisé.

Après plus de onze ans à piloter des équipes de développement au Vietnam, mon verdict est net : l’offshore fonctionne quand l’équipe distante travaille dans le système du client. Il échoue quand le client attend une boîte noire terminée. C’est cohérent avec le signal observé sur Reddit, mais celui-ci reste anecdotique : des développeurs y décrivent surtout le coût d’intégration de blocs conçus sans architecture commune. La bonne réponse n’est pas de bannir l’offshore ; c’est de rendre la propriété, la recette et la transmission vérifiables chaque semaine.

Cette logique complète le choix des fonctions à déléguer présenté dans notre guide sur l’externalisation informatique. Le contrat vient après cette décision : il transforme un périmètre choisi en engagement exploitable.

Les 12 clauses à verrouiller avant le premier jour

Le tableau ci-dessous peut servir de grille de revue avec votre avocat. Il ne remplace pas une consultation juridique adaptée au pays du client, du prestataire et des utilisateurs du logiciel.

La propriété intellectuelle mérite une rédaction précise. L’article L131-3 du Code français de la propriété intellectuelle exige que chacun des droits cédés soit mentionné distinctement et que le domaine d’exploitation soit délimité par son étendue, sa destination, son lieu et sa durée. Dans un projet logiciel, il faut donc traiter séparément le code créé pour le client, les briques antérieures du prestataire, les bibliothèques open source, le design, la documentation, les scripts d’infrastructure et les éventuels jeux de données.

Le transfert peut intervenir au paiement de chaque jalon accepté plutôt qu’à la toute fin du projet. Cette mécanique réduit le risque des deux côtés : le client ne perd pas six mois de travail en cas d’arrêt et le prestataire ne cède pas un livrable impayé. Le dépôt doit conserver l’historique complet ; envoyer une archive ZIP à la clôture ne prouve ni la provenance du code ni sa capacité à être déployé.

Pour les données personnelles, le sujet n’est pas « serveur en Europe ou non ». Il faut documenter les lieux d’hébergement, les accès de support, les sous-traitants ultérieurs et les transferts réels. La CNIL recommande de vérifier ces éléments dans les contrats critiques. Lorsqu’un transfert vers un pays hors Espace économique européen ne bénéficie pas d’une décision d’adéquation, les clauses contractuelles types de la Commission européenne peuvent fournir un mécanisme juridique, souvent complété par une analyse d’impact et des mesures techniques. Votre conseil RGPD doit confirmer le mécanisme adapté au flux réel.

Enfin, la sécurité ne doit pas se résumer à « le prestataire respecte les bonnes pratiques ». Exigez des obligations observables : authentification multifacteur, accès nominatifs, révocation sous un délai défini, chiffrement des transmissions, journalisation, notification d’incident et droit d’audit proportionné. La boîte à outils européenne publiée en février 2026 sur la chaîne d’approvisionnement ICT insiste justement sur l’identification, l’évaluation et la réduction des dépendances à risque.

Quel budget consacrer au contrôle et quel modèle choisir ?

Le contrat ne compense pas un mauvais modèle d’exécution. Un forfait convient à un projet court, stable et testable. Une régie avec un développeur dédié convient mieux à un produit vivant, dont les priorités changent avec les retours utilisateurs. Notre comparatif forfait ou régie détaille cette différence de risque.

Pour un premier engagement, je recommande de réserver 10 à 15 % du budget initial au cadrage, aux critères d’acceptation, à la sécurité, à la documentation et à la recette. Ce n’est pas une taxe juridique : ce travail réduit les reprises. Sur une enveloppe de 20 000 €, cela représente 2 000 à 3 000 €. Si cette somme évite seulement dix jours de reconstruction avec deux intervenants, elle est déjà amortie.

Le meilleur test avant un contrat de six mois reste un périmètre de dix jours ouvrés. Le prestataire doit livrer une petite fonctionnalité de bout en bout dans votre dépôt, avec tests, déploiement et documentation. Vous mesurez alors cinq choses : délai réel, qualité des échanges, autonomie, discipline de sécurité et facilité de reprise. Un portfolio montre ce que l’équipe a livré ailleurs ; ce test montre comment elle travaillera chez vous.

Voici mon critère de décision :

1. Projet ponctuel et spécification stable : choisissez un forfait avec jalons et recette détaillée.
2. Produit stratégique qui évolue : choisissez un senior dédié en régie, avec accès direct et pilotage hebdomadaire.
3. Données sensibles ou secteur réglementé : faites valider l’annexe RGPD et sécurité avant tout accès à la production.
4. Prestataire qui refuse votre dépôt ou la réversibilité : ne négociez pas le prix, changez de prestataire.

Le rituel opérationnel compte ensuite autant que le texte signé. Une revue courte et régulière du produit, du budget et des blocages évite que les écarts deviennent des litiges. Le format est décrit dans notre méthode pour piloter un développeur en régie à distance.

Verdict : testez sur un périmètre court, mais signez dès le départ comme si une autre équipe devait reprendre demain. Si le dépôt, les droits, les données et la procédure de sortie sont sous votre contrôle, l’offshore peut réduire le coût sans sacrifier la continuité. S’ils dépendent d’une promesse, le tarif journalier le plus bas est un faux calcul.