Modèle de contrat d’intégration 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 un projet d’intégration à un prestataire. Une entreprise qui achète un progiciel et demande à un tiers de l’installer, de le paramétrer selon ses processus, de reprendre ses données et de le raccorder à ses autres outils commande une prestation d’intégration. Le contrat fixe le périmètre par un cahier des charges, organise la recette et répartit les rôles entre l’intégrateur et le client. Il ne s’agit pas d’une vente de logiciel, mais d’un engagement sur un système fonctionnel.

Le projet agrège plusieurs composants. L’intégration mêle souvent une licence d’éditeur, une fourniture de matériel, du paramétrage et des développements spécifiques. Le contrat articule ces couches, précise ce que l’intégrateur produit lui-même et ce qu’il revend, et fixe la hiérarchie des documents contractuels pour trancher en cas de contradiction entre le devis, le cahier des charges et les conditions générales.

Le succès dépend d’une collaboration active du client. L’intégrateur a besoin d’accès, de données de test, de valideurs disponibles et de décisions rendues dans les délais. Le contrat formalise cette obligation de collaboration, sans laquelle un retard imputé au prestataire serait injuste, et encadre la gestion des évolutions demandées en cours de projet.

Le système traite des données personnelles. Dès que l’intégrateur accède aux données du client, ou en traite pour son compte pendant la reprise et les tests, un acte de sous-traitance conforme à l’article 28 du RGPD devient nécessaire, en complément du contrat d’intégration lui-même.

Quand ce modèle ne convient pas. Si la mission consiste à mettre à disposition un logiciel hébergé en ligne par abonnement, la qualification relève du contrat SaaS, non de l’intégration. Si le besoin se limite à écrire une application sur mesure, sans progiciel tiers ni matériel, un contrat de développement au forfait est plus adapté. Si la relation porte sur l’exploitation courante et la maintenance d’un système déjà en place, un contrat d’infogérance ou de maintenance correspond mieux. [À VÉRIFIER JURISTE : qualification exacte du contrat selon la prédominance de la fourniture de biens ou de la prestation de services.]

Ce que dit le droit français

Le contrat d’intégration est un contrat innommé à dominante d’entreprise. Aucun texte ne le nomme spécifiquement. Sa composante dominante relève du contrat d’entreprise, ou louage d’ouvrage, régi par les articles 1710 et 1787 et suivants du Code civil : l’intégrateur s’oblige à réaliser un ouvrage, un système fonctionnel, moyennant un prix. Il agrège fréquemment une licence logicielle, dont les droits sont réservés à l’auteur par l’article L122-6 du Code de la propriété intellectuelle, une fourniture de matériel relevant de la vente (articles 1582 et suivants du Code civil) et des prestations de services. Le tout reste soumis au droit commun des contrats : force obligatoire (article 1103), bonne foi (article 1104) et information précontractuelle (article 1112-1 du Code civil).

L’intégrateur est tenu d’un devoir de conseil et de mise en garde. La jurisprudence est constante : le professionnel de l’informatique doit éclairer un client profane sur l’adéquation de la solution à son besoin, l’alerter sur les risques et les prérequis, et refuser au besoin une commande vouée à l’échec. Ce devoir se double, en miroir, d’une obligation de collaboration du client, qui doit exprimer son besoin et fournir les moyens du projet. Le partage des responsabilités en cas d’échec dépend largement de la façon dont ces deux obligations ont été exécutées.

Résultat ou moyens : la qualification commande la responsabilité. Selon la précision du cahier des charges et l’engagement pris, l’intégrateur supporte une obligation de résultat sur la conformité du système livré, ou une simple obligation de moyens sur des phases exploratoires ou dépendantes du client. La différence est décisive : sous obligation de résultat, l’inexécution suffit à engager la responsabilité ; sous obligation de moyens, le client doit prouver une faute. Le contrat doit qualifier chaque engagement plutôt que de laisser le juge le faire.

La recette fixe le transfert de responsabilité. La procédure de vérification, VABF puis VSR, matérialise l’acceptation du système par le client. Elle déclenche le point de départ des garanties, le solde du prix et, souvent, le transfert des risques. Une recette mal définie, sans critères objectifs ni procès-verbal, ouvre la porte aux litiges sur la conformité et sur le moment où le système est réputé livré.

La cession des développements spécifiques obéit à un formalisme strict. Le code écrit par l’intégrateur est protégé par le droit d’auteur. Pour que le client en devienne propriétaire, une cession de droits d’auteur écrite est requise, et l’article L131-3 du Code de la propriété intellectuelle impose de mentionner distinctement chaque droit cédé, son étendue, sa destination, sa durée et son territoire. À défaut, le client ne dispose que d’un droit d’usage, pas de la propriété des développements.

Les limites de responsabilité et les pénalités connaissent des bornes. Une clause limitative de responsabilité est réputée non écrite si elle prive de sa substance l’obligation essentielle de l’intégrateur (article 1170 du Code civil, dans la lignée des arrêts Chronopost et Faurecia). La réparation reste par ailleurs limitée au dommage prévisible (article 1231-3), et les pénalités de retard constituent une clause pénale que le juge peut réviser si elle est manifestement excessive ou dérisoire (article 1231-5). Entre professionnels, les délais de paiement sont plafonnés par l’article L441-10 du Code de commerce : 60 jours, ou 45 jours fin de mois, avec indemnité forfaitaire de recouvrement de 40 euros et intérêts au taux de la BCE majoré de 10 points. [À VÉRIFIER JURISTE : articulation de la garantie des vices cachés, articles 1641 et suivants du Code civil, avec le régime de recette VABF/VSR.]

Ce que contient ce modèle, article par article

Article 1. Objet et périmètre. L’article fondateur décrit le système à mettre en place, les composants intégrés, les processus couverts, et renvoie au cahier des charges annexé. Un périmètre flou nourrit les litiges sur ce qui relève du forfait et ce qui appelle un avenant.

Article 2. Documents contractuels et hiérarchie. Le modèle énumère les pièces (conditions particulières, cahier des charges, spécifications, conditions générales) et fixe leur ordre de priorité pour résoudre les contradictions. Cette hiérarchie évite qu’un devis commercial ne prime sur les spécifications techniques validées.

Article 3. Obligations des parties. Devoir de conseil et de mise en garde de l’intégrateur d’un côté, obligation de collaboration du client de l’autre : accès, données de test, disponibilité des valideurs, décisions rendues dans les délais. L’article conditionne la répartition des torts en cas de dérive du projet.

Article 4. Nature des engagements. L’article qualifie, phase par phase, ce qui relève d’une obligation de résultat et ce qui relève d’une obligation de moyens. Cette qualification explicite prévient la requalification par le juge et clarifie la charge de la preuve.

Article 5. Planning et délais d’exécution. Jalons, dépendances, conditions de report lorsque le retard provient du client, et pénalités de retard plafonnées. L’article distingue les retards imputables à l’intégrateur de ceux causés par une carence du client.

Article 6. Recette : VABF et VSR. Cœur du contrat d’intégration. L’article organise la vérification et la recette : critères de conformité, procès-verbal, traitement des anomalies par gravité, période de service régulier, et effets de la recette définitive sur les garanties et le solde du prix.

Article 7. Gestion des évolutions. Toute demande de modification en cours de projet passe par une procédure de change request : chiffrage, impact sur le planning et le prix, validation écrite. L’article empêche la dérive silencieuse du périmètre.

Article 8. Propriété intellectuelle. L’article distingue les briques préexistantes (progiciels de l’éditeur, socle de l’intégrateur, sous licence d’utilisation) des développements spécifiques réalisés pour le client. Il organise, le cas échéant, la cession de droits d’auteur dans le respect du formalisme de l’article L131-3 du Code de la propriété intellectuelle.

Article 9. Prix, facturation et paiement. Prix forfaitaire ou décomposé, échéancier adossé aux jalons et à la recette, délai de paiement conforme au plafond de l’article L441-10 du Code de commerce, pénalités de retard. Le lien entre paiement et acceptation des livrables protège les deux parties.

Article 10. Garanties et maintenance. Garantie de conformité sur une période suivant la recette, puis passage éventuel à un contrat de maintenance corrective et évolutive. L’article évite le vide entre la fin de la garantie et le début de la maintenance.

Article 11. Responsabilité. Plafond de responsabilité, exclusion des dommages indirects, 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-3 du Code civil.

Article 12. Données personnelles. Renvoi à un acte de sous-traitance conforme à l’article 28 du RGPD lorsque l’intégrateur accède ou traite des données personnelles pendant la reprise et les tests, avec mesures de sécurité et sort des données à la fin de la mission.

Article 13. Réversibilité et fin de contrat. Documentation du système, transfert de compétences, réversibilité et restitution des données et livrables, pour que le client ne reste pas captif de son intégrateur au terme du projet.

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

Les pièges à éviter

Laisser le périmètre implicite. Un cahier des charges vague, ou renvoyé à des échanges informels, transforme chaque désaccord en litige sur ce qui était dû. Le périmètre doit être écrit, annexé et versionné, et toute demande hors périmètre traitée par une procédure d’évolution chiffrée. Sans cela, l’intégrateur subit une extension continue de sa charge, ou le client paie des fonctions qu’il croyait incluses.

Confondre livraison et recette. Installer un système n’est pas le faire accepter. Sans procédure de recette structurée, VABF puis VSR, avec critères objectifs et procès-verbal, le moment où le système est réputé conforme reste indéterminé, et avec lui le point de départ des garanties et du solde du prix. La recette est le pivot juridique du contrat, pas une formalité administrative.

Négliger le devoir de conseil. L’intégrateur qui exécute sans alerter le client sur un besoin mal exprimé, un prérequis manquant ou un risque d’inadéquation engage sa responsabilité, même si le cahier des charges venait du client. Documenter les mises en garde et les arbitrages du client protège l’intégrateur autant que la qualité du projet protège le client.

Bâcler la propriété des développements spécifiques. Une clause qui affirme, en une phrase, que le client devient propriétaire de tout ne suffit pas à céder les droits d’auteur. À défaut du formalisme de l’article L131-3 du Code de la propriété intellectuelle, la cession est fragile, et le client peut se retrouver simple utilisateur d’un code qu’il croyait détenir. La frontière avec le socle réutilisable de l’intégrateur doit aussi être posée.

Fixer une limitation de responsabilité privant l’obligation essentielle de sa substance. Un plafond dérisoire face à un système critique pour l’activité du client risque d’être réputé non écrit sur le fondement de l’article 1170 du Code civil. Le plafond doit rester proportionné à l’enjeu du projet et à la valeur du contrat, et les pénalités de retard calibrées pour ne pas être jugées manifestement excessives ou dérisoires.

Comment adapter ce modèle à votre situation

Quelques champs se renseignent systématiquement : l’identité des parties, la description du système et de son périmètre par le cahier des charges, le prix et son échéancier, le planning et ses jalons. Le reste du texte convient à la plupart des projets d’intégration courants.

La procédure de recette mérite le plus grand soin. C’est elle qui fixe le moment du transfert de responsabilité et le déclenchement des garanties. Pour un système critique, prévoyez une VSR longue, des critères de gravité d’anomalie détaillés et une recette par lots ; pour un déploiement simple, une VABF unique et une courte période d’observation peuvent suffire.

La qualification des engagements s’ajuste au niveau de définition du besoin. Quand le cahier des charges est précis et figé, une obligation de résultat sur la conformité est cohérente ; quand le projet comporte une part d’exploration ou dépend fortement de la collaboration du client, mieux vaut assumer une obligation de moyens sur ces phases et le dire clairement, plutôt que de subir une requalification.

Adaptez enfin la clause de propriété intellectuelle au contenu réel du projet. Un déploiement de progiciel standard n’appelle qu’un droit d’usage sur les licences, quand un projet comportant des développements spécifiques impose de trancher, à l’avance et selon le formalisme requis, qui détient les droits sur ce qui est créé pour le client.

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 criticité réelle du système pour votre activité, ni la nature exacte des données traitées, ni le rapport de force entre les parties. Trois situations appellent une relecture par un professionnel : un projet à fort enjeu financier ou stratégique, où la limitation de responsabilité et la propriété des développements se négocient point par point ; un traitement de données personnelles à grande échelle ou de données sensibles pendant la reprise, qui appelle un acte de sous-traitance renforcé ; et un projet articulant de multiples fournisseurs, où la répartition des responsabilités entre éditeur, intégrateur et hébergeur doit être orchestrée sans zone grise.

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.