Contrat de développement de logiciel : cession des droits, recette et modèle à adapter

Un projet logiciel dérape rarement à cause du code. Il dérape parce que personne n'a écrit ce que « terminé » veut dire, ni à qui appartiendra le résultat. Le client croit avoir acheté un logiciel, le développeur croit avoir vendu des journées de travail, et la facture finale tombe entre les deux malentendus.

Un contrat de développement de logiciel règle ces points avant que le premier commit existe : ce qui est construit, comment on constate que c'est fait, ce que cela coûte, à qui reviennent les droits. En droit français, c'est un contrat d'entreprise, le « louage d'ouvrage » de l'article 1710 du Code civil : l'une des parties s'engage à faire quelque chose pour l'autre, moyennant un prix. Le contrat existe dès l'accord (article 1172), mais deux sujets exigent un vrai document : la preuve de ce qui a été promis, et la cession des droits d'auteur, que l'article L131-2 du Code de la propriété intellectuelle (CPI) impose de constater par écrit.

Ce guide s'attarde sur les deux pièges que les modèles traduits de l'anglais ratent souvent : la cession de droits, qui doit respecter l'article L131-3 du CPI, et la recette, dont la loi ne dit rien. Il passe aussi en revue les formes de contrat, huit clauses à ne pas laisser vides, un modèle à copier, la manière de le remplir et la signature en ligne. Pour la distinction entre un contrat et un simple accord, voir notre article sur la différence entre contrat et accord ; pour la méthode générale, comment rédiger un contrat.

Un contrat de développement de logiciel est conclu entre un client et un prestataire (développeur indépendant, agence ou entreprise de services du numérique, ESN) pour réaliser un logiciel : application web ou mobile, intégration, outil interne. On parle aussi de contrat de développement informatique, de contrat de développement d'application ou, plus largement, de contrat de prestation informatique : le fond reste le même. Il fixe le périmètre, les livrables, le prix, le calendrier, les droits sur le code, la confidentialité et les conditions de sortie.

Ce n'est ni un devis, ni un cahier des charges, ni un fil de discussion qui confirme la commande. Un devis accepté peut suffire à former un contrat, mais il dit rarement qui détient le code, comment on vérifie la livraison ou ce qui se passe si le projet s'arrête à mi-chemin. C'est ce silence que le contrat comble. En cas de litige, c'est le document que le juge lira.

Ce que le contrat couvre

Un contrat sérieux traite au minimum de :

• Périmètre et livrables : ce qui est construit, avec assez de précision pour qu'un tiers puisse dire si c'est livré
• Prix et jalons : prix total, échéancier, événement qui déclenche chaque paiement
• Cession des droits : qui détient le code une fois écrit, et sur quoi exactement
• La confidentialité, c'est-à-dire ce que chaque partie doit garder pour elle
• Recette : comment le client vérifie que le logiciel répond au besoin
• La garantie : ce que le prestataire corrige, et pendant combien de temps
• Résiliation et responsabilité : comment sortir, ce qu'on paie pour le travail fait, jusqu'où chacun répond

On confond souvent ce contrat avec le cahier des charges. Il y a un recouvrement, pas une identité : le cahier des charges décrit le produit, le contrat décrit la relation, et il renvoie au cahier des charges en annexe.

Dès que quelqu'un vous paie pour construire un logiciel, ou que vous payez quelqu'un pour le faire. Un freelance pour deux semaines ou une ESN pour douze mois de produit : l'échelle change, pas le besoin d'un écrit.

Vous en avez besoin quand :

• vous externalisez le développement, surtout vers une équipe à distance ou à l'étranger, où la loi applicable n'a plus rien d'évident
• le logiciel est sur mesure : plus il est spécifique, plus la question « à qui est-il ? » pèse
• le projet avance par phases, et chaque paiement dépend d'une recette écrite
• des données personnelles passent par le projet, ce qui appelle un volet de sous-traitance au sens de l'article 28 du RGPD
• le prestataire réutilise du code qu'il a déjà écrit ou des bibliothèques open source
• le prestataire est indépendant : tant qu'aucune cession écrite n'existe, c'est lui qui reste titulaire du code (voir plus bas)

Peut-on s'en passer ? Presque jamais. Même une mission de trois jours mérite une page qui dit quoi, combien, quand et à qui appartient le résultat. Elle coûte une heure. Un malentendu sur un projet « simple » coûte beaucoup plus.

Aucun modèle ne convient à tous les projets, et celui qui prétend le contraire vend quelque chose. La structure du contrat doit suivre la façon dont le projet est chiffré et cadré, faute de quoi elle crée des incitations qui jouent contre un bon résultat.

Le forfait

Le contrat au forfait informatique est le plus répandu : le prestataire s'engage sur un périmètre et un prix, le client sait ce qu'il paiera. Tout repose sur la précision du cahier des charges : s'il est flou, chacun découvre en route qu'il n'avait pas compris la même chose. Une particularité du droit français joue ici en faveur du client : l'article 1794 du Code civil permet au maître de l'ouvrage de résilier un marché à forfait quand il veut, à condition de dédommager le prestataire de ses dépenses, de ses travaux et de ce qu'il aurait gagné. Mieux vaut chiffrer cette sortie dans le contrat que la laisser au juge.

La régie

Vous payez le temps passé à un taux journalier. C'est le bon choix quand le besoin se découvre en avançant. Le revers est l'absence de plafond naturel : un budget maximal et un point mensuel limitent le risque.

L'équipe dédiée

Pour un produit qui vit longtemps, une équipe dédiée fixe les règles d'une relation continue plutôt que d'une livraison unique. Les contrats des sociétés informatiques passent souvent par ce modèle avec leurs partenaires d'externalisation. Attention : un développeur indépendant intégré à vos équipes, à vos horaires et sous vos ordres expose à la requalification en salariat, comme l'explique notre article sur la différence entre indépendant et salarié.

Le contrat agile

Le « contrat agile » n'existe pas comme catégorie légale : c'est un montage. Backlog évolutif, forfait par sprint ou par lot, régie plafonnée, ou forfait à périmètre variable avec possibilité de sortir à chaque fin de sprint. La recette porte alors sur chaque incrément, pas sur « le logiciel », et le contrat doit le dire.

Contrat-cadre et SOW

Pour une relation longue, on sépare le contrat-cadre (droits, confidentialité, responsabilité, loi applicable) des SOW, ou bons de commande, qui fixent les livrables, les délais et le prix de chaque projet.

Toutes les clauses ne pèsent pas pareil. Voici les huit où un contrat se gagne ou se perd, parce qu'une formulation vague y produit de vrais litiges.

1. Périmètre et livrables

Décrivez ce qui est construit assez précisément pour qu'une personne étrangère au projet puisse dire si c'est livré : fonctions, contraintes techniques, services tiers, niveaux de performance. Nommez aussi ce qui est hors périmètre. « Faire un site » n'est pas un périmètre. « Une application Next.js responsive avec les fonctions de l'Annexe A et un score Lighthouse mobile d'au moins 90 » en est un. Le flou est la première source de litiges logiciels : chacun est persuadé d'avoir été clair.

2. Prix, jalons et délais de paiement

Listez chaque paiement : montant, événement déclencheur, moyen de paiement. Liez les jalons à des livrables recettés, pas à des dates du calendrier. Entre professionnels, le délai convenu ne peut pas dépasser soixante jours après la date de la facture (article L441-10 du Code de commerce), et le contrat doit fixer le taux des pénalités de retard, qui ne peut être inférieur à trois fois le taux d'intérêt légal. L'indemnité forfaitaire de recouvrement est de 40 euros. Le détail est dans notre article sur les délais de paiement.

3. Cession des droits de propriété intellectuelle

C'est la clause que la plupart des lecteurs survolent, et celle où le droit français est le plus exigeant. Qui détient le code sur mesure ? Les briques que le prestataire avait déjà ? Les composants open source ? La cession doit nommer chaque droit cédé et en délimiter l'étendue, la destination, le lieu et la durée (article L131-3 du CPI). La section sur le droit d'auteur plus bas détaille la rédaction.

4. Confidentialité

Prévoyez une confidentialité réciproque : le prestataire ne divulgue ni vos données ni votre logique métier, vous ne divulguez pas ses outils et méthodes. Fixez une durée de survie après la fin du contrat. Pour un accord autonome, lisez le guide du NDA pour les sociétés de logiciel et comment créer un NDA solide.

5. Recette

Définissez comment le client vérifie chaque livrable : délai de vérification (cinq à dix jours ouvrés est courant), format des retours, critères de réussite, et ce qui se passe si le client ne répond pas. La loi ne définit pas la recette : tout dépend de ce que vous écrivez. Un procès-verbal de recette, avec ou sans réserves, devient le point de départ de la garantie et du paiement du jalon.

Le contrat doit aussi dire quelle est la nature de l'engagement. La loi ne tranche pas entre l'obligation de résultat (livrer un logiciel conforme au cahier des charges) et l'obligation de moyens (travailler avec diligence), et les juges regardent le contrat, la précision du cahier des charges et la part prise par le client. Un forfait aux critères de recette précis plaide pour un résultat, une régie pour des moyens. Écrivez la qualification plutôt que de laisser le juge la deviner : l'article 1.4 du modèle le fait.

6. Garantie

Le prestataire garantit que le logiciel fonctionne conformément à l'Annexe A, que le code est original (ou valablement licencié) et que sa livraison ne contrefait aucun droit de tiers. Une période de correction des anomalies après la recette (trente à quatre-vingt-dix jours en pratique) protège contre les défauts découverts après la mise en production. Précisez que la garantie ne couvre pas ce que le client a modifié lui-même.

7. Résiliation

Chaque partie doit pouvoir sortir moyennant préavis (trente jours est courant). Définissez le sort du travail en cours et le calcul du solde. Séparez la résiliation pour manquement (inexécution grave, insolvabilité, non-paiement), avec mise en demeure préalable (articles 1224 à 1226 du Code civil), de la résiliation pour convenance, qui se paie.

8. Loi applicable et juridiction

Nommez le droit applicable et le tribunal compétent. Entre un client français et un prestataire établi à l'étranger, cette clause décide quel juge tranchera le litige. Ne la laissez pas vide sous prétexte qu'elle fait « formelle » : c'est l'une des plus utiles dès qu'un prestataire est hors de France. Dans l'Union européenne, le règlement Rome I laisse les parties choisir la loi applicable.

Voici une base à adapter. Remplacez tous les champs entre crochets par vos conditions. Ce modèle est écrit pour le droit français : la clause de cession (article 3) suit l'article L131-3 du CPI. C'est, avec la garantie et la limitation de responsabilité, la partie à faire relire par un avocat spécialisé en droit de l'informatique. Un modèle est un point de départ, pas un conseil juridique.

CONTRAT DE DÉVELOPPEMENT DE LOGICIEL

Date du contrat : [date]

Le Client : [dénomination sociale, forme, capital, RCS, siège]
représenté par [nom, fonction] (« le Client »)

Le Prestataire : [dénomination sociale ou nom de l’entrepreneur individuel, SIREN, adresse]
représenté par [nom, fonction] (« le Prestataire »)

ARTICLE 1. OBJET ET PÉRIMÈTRE

1.1 Le Prestataire réalise et livre au Client le logiciel décrit dans le
cahier des charges de l’Annexe A (« le Logiciel »), selon les spécifications,
contraintes et critères de recette qui y figurent.

1.2 Toute prestation absente de l’Annexe A est hors périmètre et ne peut être
réalisée qu’après signature d’un ordre de modification (article 10).

1.3 Le Logiciel est livré par jalons, selon le calendrier de l’Annexe B.

1.4 Nature de l’engagement. Le Prestataire est tenu d’une obligation de résultat
quant à la conformité du Logiciel à l’Annexe A, et d’une obligation de moyens
pour le conseil et la maintenance.

ARTICLE 2. PRIX ET PAIEMENT

2.1 Le prix est de [montant] euros hors taxes (« le Prix »), payable par jalons
selon l’Annexe B. [Forfait, ou régie plafonnée à [montant] euros]

2.2 Les factures sont payables à [30] jours à compter de leur émission
(soixante jours au plus, article L441-10 du Code de commerce).

2.3 Tout retard entraîne des pénalités au taux de [taux] % (au moins trois fois
le taux d’intérêt légal) et l’indemnité forfaitaire de recouvrement de 40 euros.

2.4 Le Prestataire peut suspendre les travaux si une facture reste impayée
[30] jours après son échéance, après mise en demeure.

ARTICLE 3. PROPRIÉTÉ INTELLECTUELLE

3.1 Cession. Sous réserve du paiement intégral du Prix, le Prestataire cède au
Client, à titre exclusif, les droits patrimoniaux d’auteur sur les
développements spécifiques réalisés pour lui (« les Développements »), code
source, code objet et documentation compris, à savoir :
a) le droit de reproduction, permanente ou provisoire, par tout moyen et
   sous toute forme ;
b) le droit de traduction, d’adaptation, d’arrangement et de toute autre
   modification, et de reproduction du logiciel qui en résulte ;
c) le droit de mise sur le marché, à titre onéreux ou gratuit, y compris
   par location.
Étendue et destination : tous usages du Client, y compris l’exploitation
commerciale auprès de tiers [ou : les seuls besoins internes du Client].
Lieu : monde entier. Durée : toute la durée de protection des droits
patrimoniaux, prorogations comprises.

3.2 Rémunération. La cession est consentie moyennant le Prix, qui rémunère
forfaitairement les droits cédés (article L131-4, 5°, du CPI).

3.3 Droits moraux. Dans les limites de l’article L121-7 du CPI, le Prestataire
ne s’oppose pas à la modification du Logiciel par le Client.

3.4 Éléments préexistants. Le Prestataire reste titulaire des outils et
composants antérieurs au projet ou indépendants de lui, listés en Annexe A
(« les Éléments Préexistants »). Il en concède au Client une licence non
exclusive, mondiale, perpétuelle et sans redevance, pour les utiliser tels
qu’intégrés au Logiciel.

3.5 Open source. Les composants open source du Logiciel sont listés en
Annexe A avec leurs licences. Le Prestataire garantit que leur usage est
compatible avec l’exploitation prévue au 3.1.

3.6 Chaîne de droits. Le Prestataire garantit détenir les droits nécessaires,
y compris ceux de ses salariés (article L113-9 du CPI) et ceux de ses
sous-traitants, qui lui ont cédé les leurs par écrit, et que les
Développements ne contrefont aucun droit de tiers.

ARTICLE 4. CONFIDENTIALITÉ

4.1 Chaque partie garde confidentielles les informations non publiques que
l’autre lui communique dans le cadre du contrat, pendant [2/3/5] ans après
sa fin.

4.2 Sont exclues les informations publiques sans faute de la partie qui les
reçoit, déjà connues d’elle, ou dont la loi ou un juge impose la divulgation.

ARTICLE 5. DONNÉES PERSONNELLES

Si le Prestataire traite des données personnelles pour le compte du Client,
les parties signent avant tout traitement l’accord de sous-traitance de
l’Annexe C (article 28 du RGPD).

ARTICLE 6. RECETTE

6.1 À chaque livraison de jalon, le Client dispose de [10] jours ouvrés pour
vérifier le livrable au regard des critères de l’Annexe A, puis prononcer la
recette ou notifier par écrit les anomalies.

6.2 Le Prestataire corrige les anomalies bloquantes sous [10] jours ouvrés,
sans frais ; les anomalies mineures sont consignées en réserves et ne
bloquent pas la recette.

6.3 Sans réponse du Client à l’issue du délai, le Prestataire le relance par
écrit. Sans réponse sous [5] jours ouvrés, la recette est réputée prononcée.

6.4 Un procès-verbal de recette est signé par les deux parties à chaque jalon.

ARTICLE 7. GARANTIE

Pendant [90] jours après la recette finale, le Prestataire corrige sans frais
les anomalies de conformité à l’Annexe A, sauf si elles résultent d’une
modification du Logiciel ou de son environnement faite par le Client ou un tiers.

ARTICLE 8. RESPONSABILITÉ

8.1 La responsabilité de chaque partie est limitée au Prix payé au cours des
[12] mois précédant le fait générateur, sans réparation des dommages indirects.

8.2 Ces limites ne s’appliquent pas à la faute lourde ou dolosive.

ARTICLE 9. DURÉE ET RÉSILIATION

9.1 Le contrat dure jusqu’à la recette finale et le paiement du solde.

9.2 Manquement : après mise en demeure restée sans effet pendant [15] jours,
la partie lésée peut résilier le contrat (clause résolutoire, article 1225
du Code civil).

9.3 Convenance : le Client peut résilier moyennant [30] jours de préavis, et
paie les jalons recettés, les travaux en cours et [montant ou pourcentage]
au titre du gain manqué.

9.4 À la fin du contrat, le Prestataire remet le code livré, la documentation
et les accès nécessaires.

ARTICLE 10. ORDRES DE MODIFICATION

Toute modification du périmètre fait l’objet d’un ordre de modification
signé des deux parties avant tout début d’exécution. Il précise l’ajout, son
effet sur le calendrier et sur le Prix. Seuls [rôles habilités] peuvent le signer.

ARTICLE 11. LOI APPLICABLE ET LITIGES

Le contrat est soumis au droit français. À défaut d’accord amiable, tout
litige relève du [tribunal compétent, ville].

ARTICLE 12. INTÉGRALITÉ

Le contrat, ses annexes et ses ordres de modification forment l’intégralité
de l’accord des parties.

SIGNATURES

Fait à [ville], le [date], par signature électronique (articles 1366 et 1367
du Code civil).

Le Client : [nom, fonction, signature]
Le Prestataire : [nom, fonction, signature]

---
ANNEXE A. CAHIER DES CHARGES
[Fonctions, contraintes techniques, critères de recette de chaque livrable,
éléments préexistants, composants open source et licences]

ANNEXE B. JALONS ET PAIEMENTS

| Jalon | Livrable | Date | Paiement |
|-------|----------|------|----------|
| J1 : lancement | [description] | [date] | [montant] |
| J2 : [phase] | [description] | [date] | [montant] |
| J3 : livraison finale | [description] | [date] | [montant] |

ANNEXE C. ACCORD DE SOUS-TRAITANCE DES DONNÉES (si applicable)

Si vous gérez les contrats de plusieurs prestataires informatiques, garder tous les exemplaires signés au même endroit, avec l'historique des versions, vous évite les échanges de fichiers Word renommés « final_v3_VRAI ».

La plupart des modèles couvrent les bases. Voici les clauses qui disparaissent des contrats bâclés ou rédigés à la hâte, et qui comptent le plus le jour où quelque chose tourne mal.

Des critères de recette chiffrés

L'article 6 du modèle dit quand et comment le client vérifie. Ce que beaucoup de contrats omettent, ce sont les critères eux-mêmes. Sans seuils mesurables, la recette devient une négociation : le client peut toujours juger le logiciel « pas assez bien ». Écrivez des critères objectifs en Annexe A avant le début du développement.

Séquestre du code source et réversibilité

Si votre activité dépend d'un logiciel sur mesure et que le prestataire disparaît, il vous faut le code. Un séquestre dépose le code chez un tiers, qui le remet au client si le prestataire cesse son activité ou manque gravement à ses obligations. À défaut, la clause de réversibilité (remise du code, de la documentation et des accès à la fin du contrat, sans frais cachés) est le minimum. Peu de clients y pensent avant d'en avoir besoin, et la plupart des prestataires l'acceptent quand elle est demandée tôt. Pour une application mobile, ajoutez les accès : le contrat de développement d'application mobile doit dire qui est titulaire des comptes développeur des boutiques d'applications, des certificats de signature et des clés d'API.

Responsabilité après la livraison

L'article 8 plafonne la responsabilité, mais beaucoup de modèles ne disent rien de la durée. Jusqu'à quand le prestataire répond-il ? Si un défaut fait perdre des données dix-huit mois après la livraison, qui paie ? Fixez la période de garantie et la responsabilité après elle. Gardez aussi en tête que l'article 1170 du Code civil prive d'effet une clause qui vide de sa substance l'obligation essentielle du prestataire : un plafond trop bas risque de tomber.

Ordres de modification

L'article 10 exige un ordre signé pour toute modification du périmètre. Ce que beaucoup omettent : qui a le pouvoir de le signer. Si un chef de projet côté client réclame une fonction par message et que le prestataire la développe, est-elle due ? Seulement si la procédure a été suivie. Nommez des rôles, pas des personnes, qui ont l'autorité d'autoriser les changements.

Open source et données personnelles

Une bibliothèque sous licence GPL, par exemple, peut imposer de publier le code de votre produit qui l'intègre. Exigez la liste des composants open source et de leurs licences, et la confirmation de leur compatibilité avec l'usage prévu. Même logique pour les données : si le prestataire traite des données personnelles, l'article 28 du RGPD impose un contrat de sous-traitance, et mieux vaut le signer avant le premier accès à une base réelle.

La propriété intellectuelle est la clause que le client survole, et celle où les erreurs coûtent le plus. En France, elle a une règle de forme que les modèles venus de l'étranger ignorent.

La cession qui ne vaut rien

Les modèles traduits de l'anglais disent presque tous la même chose : le prestataire cède « tous droits, titres et intérêts, y compris tous les droits d'auteur ». En droit français, cela ne suffit pas. La transmission des droits est subordonnée à la condition que chacun des droits cédés fasse l'objet d'une mention distincte dans l'acte de cession, et que le domaine d'exploitation soit délimité quant à son étendue, à sa destination, au lieu et à la durée (article L131-3 du CPI). La cession globale des œuvres futures est nulle (article L131-1). Un contrat qui ne fait que reprendre la formule américaine laisse donc le client avec une cession fragile, voire sans cession.

Ce que la loi prévoit pour le logiciel

Le CPI contient des règles propres au logiciel, plutôt favorables au client :

• le droit d'exploitation du logiciel comprend la reproduction, la traduction, l'adaptation ou toute autre modification, et la mise sur le marché (article L122-6) : ce sont les trois droits à lister dans la cession
• une rémunération forfaitaire est licite en cas de cession de droits portant sur un logiciel (article L131-4, 5°), donc le prix du projet peut valoir rémunération de la cession
• l'auteur d'un logiciel ne peut pas s'opposer à sa modification par le cessionnaire, tant qu'elle ne porte atteinte ni à son honneur ni à sa réputation, et ne peut pas exercer de droit de repentir ou de retrait (article L121-7)
• l'action en révision pour lésion de l'article L131-5 n'est pas ouverte aux auteurs de logiciels

Les quatre modèles de propriété

Éléments préexistants et chaîne de droits

Presque tous les développeurs apportent des outils et des bibliothèques écrits avant votre projet. Le contrat doit les identifier et vous en concéder une licence d'usage, sans transférer la propriété de ces briques. Demandez aussi la chaîne de droits : les droits sur le code d'un salarié sont dévolus à son employeur (article L113-9), mais ceux d'un freelance sous-traitant ne le sont pas. Le prestataire ne peut vous céder que ce qu'il détient lui-même.

Le « work made for hire » n'existe pas ici

Le droit américain connaît le work made for hire : le code écrit par un salarié appartient à l'employeur. Le CPI a l'équivalent pour les employés seulement (article L113-9), pas pour les prestataires. Un contrat de louage d'ouvrage ne dérogeant pas aux droits de l'auteur (article L111-1), un indépendant ou une agence reste titulaire du code tant qu'une cession écrite conforme à l'article L131-3 n'existe pas. Pour les modèles de contrat web et logiciel, la bibliothèque de modèles Chaindoc fournit une base d'édition ; la rédaction de la cession reste à adapter à votre cas.

Ces documents se confondent sans cesse. En bref : un contrat de développement pour un projet isolé, un contrat-cadre plus un SOW pour une relation qui dure. Chacun a un rôle, et les mélanger crée des trous de responsabilité.

Pour un projet isolé, un contrat unique comme celui de ce guide suffit. Pour un partenaire de développement avec qui vous menez plusieurs projets, l'ensemble contrat-cadre et SOW est plus efficace : vous négociez le socle juridique une fois, puis chaque projet ajoute un SOW.

Faire signer un contrat de développement de logiciel voulait dire imprimer, scanner, envoyer et espérer que les deux versions soient identiques. Il n'y a plus aucune raison de procéder ainsi.

Ce qui rend une signature électronique valable

Pour un contrat commercial, une signature électronique tient lorsqu'elle remplit ces conditions :

• elle identifie son auteur (article 1367 du Code civil)
• elle manifeste son consentement à l'acte
• elle est liée à l'acte signé, dont l'intégrité est garantie
• l'écrit est conservé dans des conditions qui en garantissent l'intégrité (article 1366)

La présomption de fiabilité prévue par l'article 1367 s'attache aux signatures électroniques qualifiées, selon le décret n° 2017-1416. Une signature simple reste recevable, mais c'est à celui qui s'en prévaut d'en démontrer la fiabilité. Les signatures cryptographiques vont plus loin : chacune est liée mathématiquement au hash du document, et changer un seul caractère après coup change l'empreinte. Aucune partie ne peut ensuite soutenir que le document a été modifié sans que cela se voie.

Comment se déroule la signature

Un contrat d'informatique est rarement seul : contrat-cadre, SOW, NDA, avenants circulent en même temps. Un circuit de signature dédié évite le désordre des versions échangées par e-mail :

• téléversez le contrat finalisé, annexes comprises, en un seul fichier
• ajoutez l'adresse e-mail de chaque signataire ; tous sont invités en même temps, et un ordre fixe passe par les circuits d'approbation du plan Business
• chaque signataire signe depuis son appareil
• le service établit un certificat de signature, avec les horodatages et l'empreinte du document
• chaque partie conserve le document signé, et la preuve peut ensuite être vérifiée avec le service de vérification de Chaindoc

Jalons et facturation

Le plus utile, dans un outil de contrats, n'est pas la signature elle-même, c'est ce qui vient après. Le procès-verbal de recette d'un jalon est un document qui se signe comme le contrat, et il déclenche la facture. Pour les équipes qui suivent paiements et contrats, signer le procès-verbal au même endroit que le contrat garde recette et facturation alignées. Les offres sont détaillées sur la page des tarifs, et le service de signature est présenté sur la page de la signature électronique.

Textes de référence

• Code civil, articles 1366 et 1367 sur l'écrit et la signature électroniques
• Code de la propriété intellectuelle, article L131-3 sur la cession des droits d'auteur
• Code de la propriété intellectuelle, articles L122-6 et L121-7 sur les droits propres au logiciel
• Règlement (UE) n° 910/2014 (eIDAS)
• Code de commerce, article L441-10 sur les délais de paiement
• Service-public.fr : délais de paiement entre professionnels

D'autres guides pratiques sont sur le blog Chaindoc.