Modèle de contrat de prestation informatique gratuit (Word)

Sommaire

1. Quand utiliser ce contrat, et quand il ne convient pas
2. Ce que dit le droit français
3. Ce que contient ce modèle, article par article
4. Les pièges à éviter
5. Comment adapter ce modèle à votre situation
6. Ce que ce modèle ne remplace pas

Quand utiliser ce contrat, et quand il ne convient pas

Vous confiez une tâche informatique définie à un prestataire. Une entreprise qui fait réaliser un développement spécifique, une intégration d’outils, une reprise de données ou une prestation de conseil technique commande un travail dont le périmètre est décrit à l’avance. Le contrat de prestation informatique fixe le cahier des charges, les délais, le prix et les conditions de recette. C’est le contrat de référence quand la prestation est cadrée par un résultat attendu plutôt que par une mise à disposition de moyens humains au temps passé.

Vous vendez une prestation de services informatiques. Une société de services (ESN), un intégrateur ou un développeur indépendant qui facture un projet au forfait utilise le même contrat, en position de prestataire. La vigilance porte alors sur le périmètre exact du livrable, le partage entre obligation de moyens et obligation de résultat, et la limitation de sa responsabilité.

La prestation produit des livrables sur mesure. Dès qu’un logiciel, un module ou un paramétrage est développé spécifiquement pour le client, la question de la propriété des développements devient centrale. Le contrat doit trancher, à l’avance, qui détient les droits sur ce qui est créé, faute de quoi le client risque de payer un développement dont il ne devient pas titulaire.

La prestation donne accès à des données personnelles. Si le prestataire manipule des données de clients, de salariés ou de prospects pour le compte de l’entreprise, il agit comme sous-traitant au sens de l’article 28 du RGPD. Le contrat doit alors être adossé à un acte de sous-traitance encadrant instructions, sécurité et confidentialité.

Quand ce modèle ne convient pas. Si la relation consiste à mettre du personnel à disposition, facturé au temps passé sous le pilotage du client, la logique relève de la régie informatique, non du forfait de résultat. Si le prestataire prend en charge, de façon durable, l’exploitation de tout ou partie du système d’information, un contrat d’infogérance est plus adapté. Si l’objet unique est la mise à disposition d’un logiciel hébergé par abonnement, la qualification est celle du contrat SaaS. [À VÉRIFIER JURISTE : frontière entre forfait, régie et infogérance selon le mode réel de pilotage de la prestation.]

Ce que dit le droit français

La prestation informatique est un contrat d’entreprise. Le prestataire réalise un travail au profit du client sans lien de subordination : la qualification est celle du louage d’ouvrage, ou contrat d’entreprise, régi par les articles 1710 et 1779, 3° du Code civil. C’est un contrat consensuel, synallagmatique et à titre onéreux, innommé quant à son objet technique mais soumis au droit commun des contrats issu de l’ordonnance du 10 février 2016 (articles 1101 et suivants du Code civil). Sa formation obéit à l’obligation d’information précontractuelle (article 1112-1), aux conditions de validité (article 1128) et au régime des vices du consentement (articles 1130 et suivants).

Le prestataire est tenu d’une obligation de moyens, sauf stipulation contraire. Sur un travail dont le résultat dépend en partie de facteurs qu’il ne maîtrise pas seul, le prestataire s’engage en principe à une obligation de moyens : mettre en œuvre les diligences et compétences attendues d’un professionnel. Une obligation de résultat ne pèse sur lui que si le contrat la prévoit pour un livrable défini, par exemple la conformité à un cahier des charges validé. Le régime de responsabilité contractuelle se fonde sur l’article 1231-1 du Code civil, et les sanctions de l’inexécution sur l’article 1217.

Le prestataire doit conseiller et mettre en garde ; le client doit collaborer. La jurisprudence met à la charge du prestataire informatique une obligation renforcée de conseil et de mise en garde : il doit alerter le client sur l’adéquation de la solution à ses besoins et sur les risques du projet. En contrepartie, le client est tenu d’un devoir de collaboration : exprimer clairement ses besoins, fournir les informations et accès nécessaires, participer à la recette. Le partage de responsabilité en cas d’échec du projet se joue souvent sur cet équilibre.

La propriété du code ne se transfère pas avec le paiement. Le paiement de la prestation n’emporte aucune cession des droits d’auteur sur les développements réalisés. Pour que le client devienne titulaire du code, une cession de droits d’auteur conforme à l’article L. 131-3 du Code de la propriété intellectuelle est nécessaire : chaque droit cédé doit être mentionné distinctement, avec son étendue, sa destination, son lieu et sa durée. À défaut, le client ne dispose que d’une simple licence d’utilisation, dans les limites de l’article L. 122-6 du même code. Lorsque le développement est réalisé par des salariés du prestataire, la dévolution des droits obéit à l’article L. 113-9 du Code de la propriété intellectuelle.

Les clauses limitant la responsabilité connaissent des bornes. Entre professionnels, un plafond de responsabilité et l’exclusion des dommages indirects sont licites, mais une clause qui prive de sa substance l’obligation essentielle du prestataire est réputée non écrite, en application de l’article 1170 du Code civil (jurisprudence Chronopost, puis Faurecia). Une pénalité de retard stipulée relève de la clause pénale de l’article 1231-5, que le juge peut modérer si elle est manifestement excessive ou dérisoire. La limitation de responsabilité ne joue pas non plus en cas de faute lourde ou dolosive.

Le traitement de données et la sous-traitance sont encadrés. Si le prestataire traite des données personnelles pour le compte du client, l’article 28 du RGPD impose un acte de sous-traitance contraignant. Le recours à des sous-traitants pour exécuter tout ou partie de la prestation relève par ailleurs de la loi n° 75-1334 du 31 décembre 1975 relative à la sous-traitance. Les délais de paiement entre professionnels sont plafonnés à 60 jours par l’article L. 441-10 du Code de commerce, assortis de pénalités et d’une indemnité forfaitaire de 40 euros (article D. 441-5). L’action se prescrit par cinq ans (article 2224 du Code civil). [À VÉRIFIER JURISTE : articulation moyens/résultat selon le livrable, quantum des pénalités de retard et références jurisprudentielles précises.]

Ce que contient ce modèle, article par article

Article 1. Objet et périmètre de la prestation. L’article fondateur décrit la nature du travail confié et renvoie au cahier des charges, pièce qui détaille les besoins, les fonctionnalités et les contraintes techniques. Un périmètre imprécis nourrit les litiges sur ce qui relève du forfait et ce qui appelle un avenant facturé.

Article 2. Livrables et délais d’exécution. Liste des livrables, jalons, calendrier et conséquences du retard. L’article distingue les échéances contraignantes des dates indicatives, et articule le planning avec le devoir de collaboration du client, dont les retards peuvent décaler la livraison.

Article 3. Nature de l’engagement. Le modèle précise, livrable par livrable, si le prestataire est tenu d’une obligation de moyens ou d’une obligation de résultat. Cette qualification commande le régime de preuve en cas de litige et mérite d’être arrêtée sans ambiguïté.

Article 4. Recette et réception. Modalités de vérification d’aptitude au bon fonctionnement (VABF) et de vérification de service régulier (VSR), délais de recette, traitement des réserves et effet de la réception. La recette matérialise l’accord du client sur la conformité du livrable et fait courir les garanties.

Article 5. Prix et modalités de paiement. Montant du forfait ou des unités d’œuvre, échéancier adossé aux jalons, délai de paiement conforme au plafond de l’article L. 441-10 du Code de commerce, pénalités de retard. Un projet au forfait appelle un prix ferme, un projet évolutif un mécanisme de gestion des changements.

Article 6. Propriété intellectuelle. L’article organise le sort des développements spécifiques et, le cas échéant, la cession des droits d’auteur conforme à l’article L. 131-3 du Code de la propriété intellectuelle. Il distingue le socle et les outils préexistants du prestataire de ce qui est créé pour le client, et fixe le périmètre de la cession ou de la licence.

Article 7. Données personnelles et sécurité. Lorsque la prestation donne accès à des données personnelles, l’article renvoie à un acte de sous-traitance conforme à l’article 28 du RGPD et détaille les mesures de protection des données, les instructions du client et la restitution en fin de mission.

Article 8. Confidentialité. Chaque partie protège les informations sensibles reçues de l’autre. Le prestataire accède fréquemment au système d’information et aux données stratégiques du client, ce qui justifie un engagement ferme, distinct des mesures de sécurité techniques.

Article 9. Maintenance et évolutions. Le cas échéant, l’article encadre la correction des anomalies après recette, la période de garantie, puis les prestations de maintenance et d’évolution, avec leurs niveaux de service et leur facturation propre.

Article 10. Responsabilité. Plafond de responsabilité, exclusion des dommages indirects, et rappel que la limitation ne joue ni pour la faute lourde ou dolosive, ni au point de vider l’obligation essentielle de sa substance. La rédaction reste dans les bornes des articles 1170 et 1231-1 du Code civil.

Article 11. Caractère intuitu personae et sous-traitance. Le contrat est conclu en considération des compétences du prestataire. L’article encadre le recours à des sous-traitants et rappelle l’autonomie d’exécution, afin d’écarter tout lien de subordination.

Article 12. Durée, résiliation et réversibilité. Durée de la prestation, conditions de résiliation, puis organisation de la fin de mission : restitution des livrables, de la documentation, des codes sources et des accès, pour que le client ou un tiers puisse reprendre la main.

Article 13. Droit applicable et litiges. Droit français, langue du contrat et règlement des différends, le cas échéant précédé d’une étape amiable.

Les pièges à éviter

Laisser le périmètre flou. Un cahier des charges imprécis est la première cause de litige informatique. Sans description détaillée des besoins et des livrables attendus, chaque partie interprète le forfait à son avantage, et l’échec du projet devient impossible à imputer. Le cahier des charges doit être annexé et opposable, pas résumé en quelques lignes.

Confondre obligation de moyens et obligation de résultat. Promettre un résultat sans le vouloir, ou au contraire ne rien garantir sur un livrable pourtant mesurable, expose les deux parties. Le contrat doit qualifier l’engagement livrable par livrable, car cette distinction commande qui devra prouver quoi en cas de désaccord sur la conformité.

Oublier la cession des droits sur le code. Payer un développement spécifique ne rend pas le client propriétaire du code. Sans clause de cession conforme à l’article L. 131-3 du Code de la propriété intellectuelle, mentionnant chaque droit, son étendue, sa destination, sa durée et son lieu, le client ne dispose que d’un droit d’usage, et une cession mal rédigée encourt la nullité. Ce point se règle avant la livraison, pas après.

Négliger la recette. Sans procédure de recette écrite, le désaccord sur la conformité du livrable n’a pas d’arbitre. La recette fixe les critères de validation, le délai imparti au client pour vérifier et le sort des réserves. Une réception tacite non encadrée peut faire perdre au client le droit de contester des défauts pourtant réels.

Créer un lien de subordination. Lorsque le prestataire est une personne physique intégrée aux équipes du client, soumise à ses horaires et à son contrôle permanent, le contrat de prestation peut être requalifié en contrat de travail, avec un risque de redressement. L’autonomie d’exécution, la logique de livrables et le caractère intuitu personae réduisent ce risque, à condition que les faits ne contredisent pas le contrat.

Comment adapter ce modèle à votre situation

Quelques champs se renseignent systématiquement : l’identité des parties, la description de la prestation et son périmètre, le prix et ses modalités, les délais et les livrables. Le cahier des charges, annexé, porte l’essentiel du détail technique et mérite le plus grand soin.

La nature de l’engagement s’ajuste au projet. Pour un développement dont la conformité peut être objectivement vérifiée, une obligation de résultat sur le livrable final se défend ; pour une prestation de conseil ou d’assistance, l’obligation de moyens reste la règle. Fixez cette qualification livrable par livrable plutôt que d’un bloc, car un même contrat peut mêler les deux régimes.

La clause de propriété intellectuelle se règle selon le besoin réel du client. Un client qui veut pouvoir faire évoluer le logiciel par un autre prestataire a besoin d’une cession large des droits et des codes sources ; un client qui se contente d’utiliser l’outil peut se satisfaire d’une licence. Dans les deux cas, distinguez clairement le socle préexistant du prestataire de ce qui est développé pour le client.

L’encadrement des données s’ajuste enfin selon l’accès accordé. Dès que la prestation touche des données personnelles, l’acte de sous-traitance conforme à l’article 28 du RGPD n’est pas optionnel. Si la prestation se prolonge par une maintenance ou des évolutions récurrentes, ajoutez des niveaux de service et une réversibilité organisée pour la fin de la relation.

Ce que ce modèle ne remplace pas

Un modèle est un point de départ, pas un avis. Il ne connaît ni la complexité réelle du projet, ni la nature des données traitées, ni le rapport de force entre les parties. Trois situations appellent une relecture par un professionnel : un projet critique ou à fort enjeu financier, où le partage des responsabilités et le plafond de responsabilité doivent être calibrés avec soin ; une cession de droits de propriété intellectuelle sur des développements stratégiques, dont le formalisme conditionne la validité ; et une prestation confiée à une personne physique, où le risque de requalification en contrat de travail impose de vérifier l’autonomie réelle d’exécution.

C’est la raison pour laquelle ce modèle signale ses propres limites, plutôt que de se présenter comme suffisant en toute circonstance.