Comment structurer un contrat de développement sous-traité ou d'exploitation-maintenance ? — Ce que le « contrat type » de l'IPA nous apprend sur la distinction entre mandat quasi-délégué et contrat d'entreprise

« Nous avions signé un contrat d’entreprise forfaitaire, mais le développement a commencé avant que les exigences ne soient stabilisées, et nous avons fini par nous disputer sur ce qui comptait comme “terminé”. »

« Nous avons un contrat de maintenance mensuel, mais le prestataire et nous n’avions pas la même compréhension de l’étendue réelle de la maintenance. »

« Quand nous avons demandé un devis, on nous a dit que “la définition des exigences serait en mandat quasi-délégué”, mais nous ne comprenons pas pourquoi le type de contrat change d’une phase à l’autre. »

Dans le développement de systèmes externalisé, les problèmes proviennent souvent non pas de la technique, mais de la forme même du contrat.

Il se trouve qu’il existe un modèle officiel pour éclairer ce sujet : le contrat type de transaction de systèmes d’information, publié par l’IPA (Information-technology Promotion Agency, un établissement administratif indépendant).

Cet article s’appuie sur ce contrat type pour exposer, dans un langage accessible également au client, comment structurer le contrat lorsqu’on externalise — ou qu’on prend en charge — un développement sous-traité et une exploitation-maintenance.

Notez que cet article est une explication générale fondée sur les documents publiés par l’IPA, et non un avis juridique. Pour tout contrat particulier, veuillez consulter un avocat ou un autre spécialiste.

1. La conclusion, d’abord

Voici, résumée en amont, la logique que le contrat type de transaction de l’IPA propose pour les contrats de développement de systèmes et d’exploitation-maintenance.

• Ne pas regrouper l’ensemble du processus de développement dans un seul contrat ; le découper par phase (contrat en plusieurs étapes)
• Pour la phase de planification et de définition des exigences, où « ce qu’il faut construire » n’est pas encore décidé, utiliser un contrat de mandat quasi-délégué
• Pour les phases allant de la conception interne au développement et aux tests, une fois que « ce qu’il faut construire » est décidé, utiliser par défaut un contrat d’entreprise (la conception externe peut relever de l’un ou l’autre type selon le projet)
• Pour un travail continu comme l’exploitation et la maintenance, utiliser par défaut un contrat de mandat quasi-délégué
• Le client a lui aussi des obligations de coopération, comme décider des exigences et fournir des informations
• Traiter les changements de spécifications non pas par des échanges oraux, mais via une procédure documentée de gestion des changements

En un mot, le principe est le suivant : « ne pas promettre d’obligation d’achèvement pour ce qui n’est pas encore décidé, mais la promettre pour ce qui l’est » — et le type de contrat est choisi phase par phase en conséquence.

2. Qu’est-ce que le « contrat type de transaction de systèmes d’information » de l’IPA ?

Le contrat type de transaction de systèmes d’information est un document officiel qui combine un modèle de contrat d’externalisation de développement de systèmes et un commentaire l’expliquant.

Il a été initialement publié par le ministère de l’Économie, du Commerce et de l’Industrie (METI) en 2007, sous la forme de la première édition, couvrant le développement sous-traité (y compris une partie de la planification) et la maintenance-exploitation. Le contexte était une multiplication de litiges causés par des divergences de compréhension des termes contractuels entre les entreprises clientes (donneurs d’ordre) et les prestataires informatiques (sous-traitants).

La responsabilité de la révision est ensuite passée à l’IPA, et une seconde édition, alignée sur le Code civil modifié entré en vigueur en avril 2020, a été publiée le 22 décembre 2020. Cette seconde édition clarifie notamment la responsabilité en cas de non-conformité au contrat (abordée plus loin) ainsi que le positionnement du mandat quasi-délégué axé sur le résultat.

Un point de vigilance concerne le champ d’application. Ces première et seconde éditions ont été conçues à l’origine autour de développements sur mesure de grande envergure (de type cascade), comme les systèmes centraux d’entreprise, en présupposant des transactions entre entreprises disposant chacune d’un service informatique et d’une fonction juridique. Pour les transactions de plus petite envergure, ou pour les cas s’appuyant sur des logiciels progiciels ou du SaaS, un contrat type complémentaire distinct, couvrant « l’utilisation de progiciels, de SaaS/ASP, ainsi que la maintenance-exploitation », est disponible. La bonne façon de les utiliser consiste à vérifier lequel se rapproche le plus de votre propre transaction, et à considérer le texte comme une base de réflexion plutôt qu’à en recopier les clauses telles quelles. Ce que cet article présente relève également de cette partie « réflexion », utile quelle que soit l’échelle.

Ce contrat type présente les caractéristiques suivantes :

• Il a été rédigé à travers une concertation entre entreprises clientes, prestataires informatiques, associations professionnelles et experts juridiques, et conçu de manière neutre afin de ne favoriser aucune des deux parties
• Le modèle de contrat est publié au format Word et peut être adapté à votre propre transaction
• Il est accompagné d’un commentaire expliquant non seulement les clauses elles-mêmes, mais aussi pourquoi elles sont rédigées ainsi
• Des documents complémentaires sont également publiés, notamment des lignes directrices pour déterminer les spécifications de sécurité d’un contrat de développement

En somme, c’est une ressource utilisable à la fois comme base de rédaction lorsque vous préparez votre propre contrat, et comme référence de comparaison lorsque vous examinez un contrat qui vous est présenté par l’autre partie.

3. L’idée centrale : le « contrat en plusieurs étapes » — pourquoi découper le contrat par phase ?

L’idée centrale du contrat type de transaction est le contrat en plusieurs étapes.

Le développement de systèmes se déroule globalement selon les phases suivantes :

Planification et définition des exigences (décider ce qu'il faut construire)
        ↓
Conception, développement et tests (construire ce qui a été décidé)
        ↓
Recette et accompagnement au déploiement (mettre en service ce qui a été construit)
        ↓
Exploitation et maintenance (le faire fonctionner durablement)

Un contrat en plusieurs étapes est un dispositif dans lequel ces phases ne sont pas regroupées en un seul contrat, mais réparties en contrats distincts, phase par phase (ou par groupe de phases).

Pourquoi les séparer ? La raison est simple : ce que l’on peut réellement promettre diffère d’une phase à l’autre.

Avant que la définition des exigences ne soit terminée, ni le contenu ni le volume de ce qui doit être construit ne sont fixés. Figer à ce stade le montant total et le délai de l’ensemble du développement conduit à l’un des deux scénarios suivants :

• Le prestataire propose un montant plus élevé pour se prémunir contre le risque non résolu
• Un prestataire ayant accepté la mission à bas prix affirme ensuite que « cela sort du périmètre », ce qui débouche sur un litige avec le client

À l’inverse, une fois la définition des exigences terminée, ce qui doit être construit est stabilisé, et le prestataire peut proposer un devis et un engagement d’achèvement avec une précision réaliste.

Un contrat en plusieurs étapes est un dispositif qui repose sur le principe de « réévaluer le devis de la partie développement une fois la définition des exigences terminée ». Du point de vue du client, cela comporte l’inconfort de ne pas disposer d’un montant total fixé dès le départ, mais la position du contrat type est que cela génère, in fine, moins de litiges et moins de coûts inutiles que de figer l’ensemble sur la base d’un montant sans fondement dès le début.

4. Mandat quasi-délégué et contrat d’entreprise — la différence entre les deux types de contrat

Un contrat en plusieurs étapes alterne, phase par phase, entre mandat quasi-délégué et contrat d’entreprise. La différence entre ces deux types est le point le plus important de cet article.

Le contrat d’entreprise — un contrat qui promet l’achèvement

Un contrat d’entreprise est un accord qui promet : « nous achèverons ce livrable ». Le prestataire assume l’obligation d’achèvement et, en principe, ne peut réclamer de rémunération si le livrable n’est pas achevé (toutefois, si un projet s’arrête en cours de route et que la partie déjà achevée peut être isolée et profite au client, une rémunération proportionnelle à cette partie peut parfois être reconnue).

Si l’élément livré n’est pas conforme au contrat, le prestataire assume la responsabilité en cas de non-conformité au contrat. Cette notion a été restructurée à partir de l’ancienne « responsabilité pour vices cachés » lors de la modification du Code civil entrée en vigueur en 2020 : le client peut exiger une réparation (une remise en état), et, sous certaines conditions — par exemple si une réparation a été demandée dans un délai fixé sans être réalisée —, peut également exiger une réduction de la rémunération. Toutefois, si la non-conformité résulte des spécifications ou des instructions fournies par le client lui-même, ces réclamations sont, en principe, impossibles, sauf si le prestataire avait remarqué le problème sans le signaler. La seconde édition du contrat type reflète cette modification législative.

Comme ce type de contrat implique une responsabilité forte en échange de l’achèvement, il convient de l’utiliser pour les phases où l’on peut clairement définir « ce qui constitue l’achèvement ».

Le mandat quasi-délégué — un contrat qui promet un travail de professionnel

Un mandat quasi-délégué est un accord qui promet : « nous exécuterons le travail en tant que professionnels ». En contrepartie de l’absence d’obligation d’achèvement, le prestataire assume un devoir de diligence, c’est-à-dire l’obligation d’exécuter le travail avec l’attention normalement attendue d’un professionnel.

Entendre qu’il n’y a « pas d’obligation d’achèvement » peut sembler inquiétant pour un client. Mais cela ne signifie pas que l’on peut « bâcler le travail ». Un travail exécuté de manière inadéquate par un professionnel engage sa responsabilité pour manquement au devoir de diligence.

Le Code civil modifié a également formalisé un mode de rémunération axé sur le résultat pour le mandat quasi-délégué. Par opposition au type proportionnel à l’exécution (rémunération proportionnelle au travail effectué — le règlement au tarif horaire en étant un exemple typique, un forfait mensuel fixe pour un travail récurrent étant également possible), le type axé sur le résultat rémunère un résultat convenu. Pour un mandat quasi-délégué comportant un livrable, comme un document de définition des exigences, l’utilisation de ce type permet de structurer la relation comme « un mandat quasi-délégué, mais où la livraison du livrable est liée à la rémunération ».

Le choix du type selon la phase

Le contrat type de transaction prévoit globalement la répartition suivante :

Ce qu’il importe de retenir ici, ce n’est pas qu’il s’agirait simplement d’une opposition entre « le contrat d’entreprise favorise le client » et « le mandat quasi-délégué favorise le prestataire ».

Imposer un contrat d’entreprise à un travail qui n’est pas encore décidé revient à promettre une obligation d’achèvement sans critère d’achèvement clair, ce qui débouche sur un dialogue de sourds sur le point de savoir si c’est « terminé ou non ». Choisir le type de contrat adapté à la nature de la phase protège finalement les deux parties.

5. Ce qu’un contrat d’exploitation-maintenance doit préciser

L’exploitation-maintenance, une fois le développement terminé, porte en elle des germes de litiges d’une autre nature. Le plus fréquent est un décalage de compréhension sur « ce qui est réellement inclus dans le forfait mensuel de maintenance ».

L’« exploitation-maintenance » désignée en un seul terme regroupe en réalité des travaux de natures très différentes.

• Surveillance de la disponibilité, sauvegardes et maintenance périodique
• Réponse aux demandes concernant le mode d’utilisation
• Investigation initiale et rétablissement en cas d’incident
• Correction des anomalies
• Suivi des mises à jour du système d’exploitation et des middlewares
• Modifications telles que des ajouts de fonctionnalités ou des changements d’écrans

Parmi ceux-ci, un travail continu comme la surveillance, la réponse aux demandes ou l’investigation initiale relève par défaut d’une structure de mandat quasi-délégué. En revanche, les ajouts de fonctionnalités ou les modifications dont le contenu peut être clairement défini sont plus sûrs à détacher individuellement et à faire chiffrer en contrat d’entreprise, plutôt qu’à inclure de manière floue dans le contrat de maintenance.

Nous recommandons de documenter au minimum les points suivants au moment de la contractualisation :

• La ligne de partage entre ce qui est inclus dans le forfait mensuel (fixe) et ce qui ne l’est pas
• Les plages horaires de prise en charge des demandes et des interventions en cas d’incident, ainsi que le délai indicatif avant le début de la prise en charge
• La classification de gravité des incidents et la politique de réponse associée à chaque niveau
• La procédure de devis et de commande pour tout travail dépassant le périmètre du forfait
• La relation entre la responsabilité en cas de non-conformité au contrat lors du développement (couverte par une correction gratuite) et le contrat de maintenance (prestation payante)

Ce dernier point en particulier est souvent négligé. Savoir si une anomalie constatée juste après la livraison relève de la responsabilité en cas de non-conformité du contrat de développement ou d’une prise en charge au titre du contrat de maintenance est un point qui donne facilement lieu à des litiges si la durée et les conditions ne sont pas clairement précisées dans le contrat.

6. Le client a lui aussi des obligations — obligation de coopération et obligation de gestion de projet

Ceci élargit légèrement le sujet des contrats, mais c’est une idée importante que le commentaire du contrat type de transaction — ainsi que la jurisprudence — mettent en avant de manière répétée : le développement de systèmes est un travail conjoint entre le client et le prestataire, et les deux parties ont des obligations à remplir.

• Le prestataire assume l’obligation, en tant que professionnel, de gérer le projet de manière appropriée et d’expliquer les risques éventuels (obligation de gestion de projet)
• Le client assume des obligations de coopération, telles que décider des exigences, fournir des informations sur les activités métier concernées, et prendre les décisions nécessaires dans les délais requis

Autrement dit, si le client confie tout au prestataire — ce que l’on pourrait appeler une délégation totale — au motif que « nous ne comprenons pas les aspects techniques », les exigences ne se stabilisent jamais, et si le projet échoue, la propre obligation de coopération du client peut elle aussi être mise en cause.

Le contrat type de transaction intègre un mécanisme de documentation de la répartition des rôles entre les deux parties, ainsi qu’un partage de l’avancement et des points en suspens via un comité de liaison (une réunion périodique). Lu non pas tant comme un modèle de contrat que comme un livre de règles pour piloter conjointement un projet, c’est un document dont le client aussi a beaucoup à tirer.

7. Traiter les changements de spécifications via une « procédure de gestion des changements »

Il est inévitable que des demandes du type « en fait, nous aimerions modifier cet écran ainsi » apparaissent en cours de développement. Le problème n’est pas le changement en lui-même, mais le fait de le laisser progresser uniquement par des échanges oraux ou par e-mail.

• Le client pensait qu’il s’agissait « d’un changement mineur »
• Le prestataire pense : « nous l’avons pris en charge, mais la charge de travail a gonflé, et nous souhaitons facturer un supplément »

Les échanges oraux ou par e-mail peuvent servir de trace de la négociation, mais en l’absence d’un document formellement approuvé par les deux parties couvrant le périmètre, le coût et l’impact sur le délai du changement, on tombe facilement, une fois cette situation atteinte, dans un dialogue de sourds.

Le contrat type de transaction définit une procédure de gestion des changements. Le déroulement, dans les grandes lignes, est le suivant :

Proposition de changement (par l'une ou l'autre partie)
        ↓
Présentation écrite (proposition de changement) du contenu, du périmètre d'impact, du coût et de l'impact sur le délai
        ↓
Concertation entre les deux parties
        ↓
En cas d'accord, le changement est mis en œuvre et consigné par écrit / en l'absence d'accord, on poursuit selon les modalités initiales

Le point clé est de se mettre d’accord sur l’impact en coût et en délai, en même temps que sur le contenu du changement, avant de commencer les travaux. Cela représente une étape supplémentaire dans la procédure, mais c’est précisément cette étape qui évite les désaccords du type « on se l’était dit / on ne se l’était pas dit ».

8. Il existe un contrat type dédié pour le développement agile

Tout ce qui a été expliqué jusqu’ici présuppose un contrat de type cascade, où l’on décide d’abord des exigences avant de construire.

En revanche, pour le développement agile — où les exigences sont révisées au fur et à mesure de la construction —, un contrat type dédié, le contrat type de transaction de systèmes d’information (édition développement agile), a été publié le 31 mars 2020.

L’édition agile présente les caractéristiques suivantes :

• Elle repose par défaut sur un contrat de mandat quasi-délégué, car l’agile est une méthode qui présuppose l’ajout, la modification et la reprioritisation des fonctionnalités au fil du développement, ce qui ne correspond pas à une structure de contrat d’entreprise fixant le livrable dès le départ
• Elle adopte Scrum comme méthodologie de développement et intègre la répartition des rôles (comme le product owner) directement dans le contrat
• Elle est accompagnée d’une check-list préalable au contrat, structurée pour que le client et le prestataire vérifient ensemble l’objectif du projet et leur compréhension mutuelle du développement agile avant de procéder à la signature

La logique n’est pas « c’est de l’agile, donc le contrat peut rester flou », mais bien « précisément parce qu’il s’agit d’un développement qui s’adapte au changement, les rôles et la démarche doivent être rendus explicites dans le contrat ».

Résumé

Voici un résumé de la réflexion sur les contrats de développement sous-traité et d’exploitation-maintenance que l’on peut tirer du contrat type de transaction de systèmes d’information de l’IPA.

• Ne pas regrouper l’ensemble du développement dans un seul contrat ; le découper par phase (contrat en plusieurs étapes)
• La planification et la définition des exigences, où l’on décide « ce qu’il faut construire », relèvent du mandat quasi-délégué ; le développement à partir de la conception interne, où ce qui doit être construit est déjà fixé, relève par défaut du contrat d’entreprise (la conception externe pouvant relever de l’un ou l’autre)
• Le contrat d’entreprise engage l’obligation d’achèvement et la responsabilité en cas de non-conformité au contrat, tandis que le mandat quasi-délégué engage le devoir de diligence : la nature de la responsabilité du prestataire diffère entre les deux
• L’exploitation-maintenance relève par défaut du mandat quasi-délégué, avec une ligne de partage entre le périmètre forfaitaire et les travaux au devis individuel documentée dès la contractualisation
• Le client a lui aussi des obligations de coopération, et une délégation totale au prestataire expose le projet à l’échec
• Les changements de spécifications doivent passer par une procédure de gestion des changements, avec un accord conjoint sur l’impact en coût et en délai
• Le développement agile dispose de son propre contrat type dédié, reposant par défaut sur une structure de mandat quasi-délégué

Le modèle de contrat type et son commentaire peuvent être téléchargés gratuitement, au format Word, depuis le site web de l’IPA. Que vous soyez sur le point d’externaliser un développement ou que l’on vienne de vous remettre un contrat à examiner, c’est un document qui mérite d’être lu au moins une fois.

Pour ceux qui envisagent d’externaliser un développement ou une maintenance de système

Choisir la bonne structure contractuelle suppose au préalable d’avoir clarifié « ce qui doit être construit », « jusqu’où va l’externalisation » et « comment les rôles sont répartis entre le client et le prestataire ».

Chez Komura Software LLC, lorsque nous prenons en charge des demandes de développement sous-traité ou de maintenance d’applications métier Windows et de systèmes web, nous proposons de suivre la logique de contrat en plusieurs étapes décrite dans cet article, en séparant l’étape de clarification des exigences de l’étape de développement. Même si vous en êtes encore au stade de la clarification du périmètre de développement et des livrables, vous pouvez tout à fait commencer par un simple échange sur votre activité actuelle.

Articles associés

Articles récents partageant les mêmes étiquettes, pour approfondir des sujets proches.

Sujets associés

Ces pages replacent le sujet dans un contexte plus large de services et de décisions.

Services liés à ce sujet

Cet article est directement lié aux services suivants.

Questions fréquentes

Questions souvent posées lors d’une consultation sur le sujet de cet article.

Quelle est la différence entre un contrat d'entreprise et un contrat de mandat quasi-délégué ?

Un contrat d'entreprise (ukeoi) rémunère « l'achèvement d'un livrable convenu », et le prestataire assume à la fois l'obligation d'achèvement et la responsabilité en cas de non-conformité au contrat. Un contrat de mandat quasi-délégué (jun-inin) rémunère « l'exécution d'un travail en tant que professionnel » (dans sa variante axée sur le résultat, la rémunération est liée à un résultat convenu), et le prestataire est tenu à un devoir de diligence en tant que professionnel, mais n'assume pas d'obligation d'achèvement. Les phases où l'on peut clairement définir ce qui doit être construit et le critère d'achèvement se prêtent à un contrat d'entreprise ; les phases qui accompagnent la réflexion propre du client, ou qui consistent en un travail continu, se prêtent à un contrat de mandat quasi-délégué.

Pourquoi recommande-t-on un contrat de mandat quasi-délégué pour la phase de définition des exigences ?

Parce que la définition des exigences est la phase où c'est le client, et non le prestataire, qui décide en premier lieu « ce qu'il faut construire », le prestataire se contentant d'accompagner cette réflexion. De plus, comme le livrable ne peut souvent pas être fixé de manière concrète dès le départ, promettre une obligation d'achèvement (un engagement de type contrat d'entreprise) à ce stade laisse le critère d'achèvement flou et devient une source de litiges. Le contrat type de l'IPA prévoit lui aussi une structure de mandat quasi-délégué pour la phase de planification et de définition des exigences.

Pour l'exploitation-maintenance, vaut-il mieux un contrat d'entreprise ou un contrat de mandat quasi-délégué ?

Un travail continu comme la surveillance de la disponibilité, le traitement des demandes ou l'investigation initiale des incidents ne correspond pas à la notion d'« achèvement » : le mandat quasi-délégué est donc la base par défaut. En revanche, les ajouts de fonctionnalités ou les modifications d'écrans dont le contenu et les critères d'achèvement peuvent être clairement définis peuvent être détachés individuellement et contractualisés en contrat d'entreprise. Il est important de documenter, dès la conclusion du contrat, ce qui est précisément inclus dans le forfait mensuel de maintenance et ce qui fait l'objet d'un devis séparé.

Le contrat type de l'IPA peut-il être utilisé tel quel ?

Le contrat type est publié au format Word en partant du principe qu'il sera adapté à votre propre transaction. Comme il est rédigé dans une position neutre, ne favorisant ni l'entreprise cliente ni le prestataire informatique, il est utile comme base de départ pour rédiger votre propre contrat, ou comme référence de comparaison lors de l'examen d'un contrat qui vous est présenté. Cela dit, pour toute décision contractuelle individuelle, nous recommandons de consulter un avocat ou un autre spécialiste.

Profil de l’auteur

Page de présentation de l’auteur de l’article.

Go Komura

Représentant de KomuraSoft LLC

Spécialisé dans le développement de logiciels Windows, le conseil technique et l’analyse de pannes, notamment pour les systèmes existants et les incidents difficiles à reproduire.