Les enjeux technologiques du numérique pour les entreprises
Les enjeux liés aux technologiques du numérique sont de plus en plus nombreux pour les entreprises. Qu’il s’agisse de la protection des données personnelles, des exigences de cybersécurité ou du recours à des outils d’intelligence artificielle, les sujets ne manquent pas pour occuper les Directions Informatiques et les Directions juridiques. Il est cependant un sujet qui, s’il est moins récent, innerve toutes les activités de l’entreprise : la gestion des contrats informatiques.
Importance du système d’information dans l’entreprise
En effet, le système d’information de l’entreprise constitue son centre névralgique : c’est le système d’information qui permet aux préposés de travailler efficacement au quotidien ; c’est le système d’information qui permet l’hébergement des données ; c’est le système d’information qui assure la sécurité des actifs incorporels, l’approvisionnement et la gestion des stocks, la vente en ligne des produits (notamment dans le cas des sites web marchands), la gestion des fournisseurs, la gestion des ressources humaines et la paie des salariés, l’envoi de la prospection commerciale, la relation avec les distributeurs, etc. Les contrats informatiques soutiennent intrinsèquement les exigences de fonctionnement, d’efficacité, de maîtrise des coûts, de sécurité et de souveraineté de l’entreprise.
Négociation des contrats informatiques
La négociation de ces contrats implique donc de recourir à des expertises spécifiques, car on ne négocie pas un contrat informatique comme une autre acquisition. Cette négociation implique de connaître les concepts techniques, de comprendre les besoins du client et la logique des fournisseurs, d’identifier leurs limites, et de respecter un contexte réglementaire complexe.
Bonnes pratiques pour la gestion des contrats informatiques
En outre, la négociation n’est pas menée pareillement selon que l’entreprise acquiert un service cloud de type SaaS ou IaaS fourni par un grand cloud provider du marché, qu’elle organise au contraire un projet d’intégration d’ERP spécifique liés précisément à ses besoins, ou qu’elle recourt à des services récurrents tels que l’hébergement de données, la TMA ou l’outsourcing.
On doit savoir appréhender les concepts et enjeux propres aux contrats de projets (déploiement d’ERP, intégration de CRM, interfaçage de systèmes, migrations de données ou d’applications), et les distinguer des concepts et enjeux propres aux contrats de services « récurrents » (licence de logiciel, souscription cloud, maintenance, infogérance…).
Face à la grande diversité des contrats informatiques, on recommande ci-après quelques bonnes pratiques et réflexes à adopter dans leur négociation:
- Définir clairement les besoins
Tout d’abord, l’entreprise doit savoir clairement déterminer son besoin, lors d’une phase interne de définition préalable de ses exigences. Là où les grandes entreprises savent rédiger des cahiers des charges (ou CCTP s’agissant d’entreprises soumises à la commande publique), d’autres sont moins au fait de cette nécessité, et préfèrent adopter des services « sur l’étagère », ou se contentent d’une expression de besoin très « macro » qui risque d’engendrer des insatisfactions ultérieures, lorsqu’il faudra entrer dans le détail des besoins en phase de conception.
Il est crucial déterminer, dès avant la contractualisation, si la démarche de l’entreprise est d’adopter un outil du marché en l’état afin de capitaliser sur ses fonctionnalités, ou s’il s’agit au contraire de construire une solution spécifique « maison ». Bien souvent d’ailleurs, le besoin se situe entre les deux, pour bénéficier des fonctionnalités issues du marché mais en les adaptant aux pratiques de l’entreprise ou aux particularités de son marché.
Il est donc nécessaire de définir non seulement les besoins fonctionnels auxquels l’outil informatique doit répondre, non seulement les contraintes techniques et architecturales, mais aussi la « philosophie du projet », et les ressources qu’on peut y consacrer.
- Considérer les spécificités des services cloud
En particulier, il faut avoir conscience, en cas d’acquisition d’un service cloud du marché, que sauf cas particulier, son éditeur ne procède à aucun développement spécifique ; il s’agit d’adopter les fonctionnalités standards proposées en s’assurant, sous la responsabilité du client, qu’elles lui conviennent. En outre, les plus grands cloud providers du marché proposent un grand nombre d’options et de configurations, mais c’est là encore au client de prendre garde, lors de l’utilisation des ressources qui sont ainsi mises à disposition, aux choix opérationnels qu’il fait. Ainsi, beaucoup de sujets (dont la sécurité des données ou les niveaux de service) échappent de facto à la négociation, et sont imposés dans le cadre d’un contrat « d’adhésion ».
- Recourir à des conseils externes si nécessaire
Au besoin, en fonction de ces ressources et expertises internes du client, il doit être recouru explicitement aux conseils du prestataire, voire à des services tiers d’assistance à maîtrise d’ouvrage. Ces prestations impliquent elles-mêmes un encadrement contractuel spécifique, pour définir la marge de manœuvre et le rôle de l’AMOA.
- Penser à long terme
Dans l’expression de besoin, on ne doit pas oublier de penser à long terme, et donc d’envisager les performances attendues (temps de réponse, volumétrie de données), ainsi que le maintien en conditions opérationnelles et les niveaux de service exigés (disponibilité et maintenance corrective en particulier).
Les besoins de l’entreprise sont plus ou moins matures ; dans le cas des contrats de projets, on doit savoir si l’expression de besoin est stabilisée, complète et précise, ou si au contraire on doit adopter une démarche plus prospective, à laquelle correspondent mieux les méthodes agiles de développement logiciel. Le recours à ces méthodes agiles implique alors la rédaction d’une méthodologie particulière, et son appréhension réfléchie dans le contrat, car elles induisent des concepts spécifiques. Ce point est très important, le client devant parfaitement comprendre quelles sont les implications pour lui du recours à ce type de méthode (ex : CA Paris, 22 mars 2024, n°21/07008).
- Définir la maîtrise d’œuvre
Par ailleurs, toujours dans les contrats de type « projet », la définition de la maîtrise d’œuvre est capitale ; plus d’un projet a achoppé sur un défaut de pilotage, et il est nécessaire de soigneusement définir qui pilote le projet et le rôle de chacun (RACI). Cette notion doit être traitée dans le contrat, y compris en cas de méthode agile.
- Obligation de conseil et d’alerte du prestataire
Outre la maîtrise d’œuvre, on doit s’interroger sur l’étendue de l’obligation de conseil et d’alerte du prestataire, et soigneusement la caractériser dans le contrat, en fonction notamment de la nature du projet et des compétences du client lui-même. Il existe ici un déséquilibre structurel entre un prestataire réputé spécialiste de son domaine d’intervention, et un client nécessairement plus profane, quand bien même il dispose d’expertises internes en matière de systèmes d’information (ex : CA Versailles, 25 mai 2023, n° 21/07620, CA Rennes, 19 sept. 2023, n° 21/03352, ou à l’inverse, CA Lyon, 7 sept. 2023, n° 19/03082). La jurisprudence regorge d’exemples sur le défaut de conseils qui, s’ils avaient été dispensés à temps et de manière diligente, auraient évité la dérive d’un projet ou l’inflation de ses coûts (ex : CA Paris, 21 avr. 2023, n° 21/00124).
Le pendant de cette obligation du prestataire réside dans l’obligation de collaboration du client : lui seul est en capacité d’exprimer ses besoins, même s’il peut s’appuyer sur des prestations de cadrage et les préconisations du prestataire ; lui seul est en mesure de prononcer ses arbitrages et de définir ses priorités, notamment en cas de méthode agile. Ses métiers doivent être parties prenantes durant tout le projet, et son propre pilotage, dans le cadre de sa maîtrise d’ouvrage, doit être tracé et cohérent. En particulier, on doit être très vigilant face aux risques de demandes surnuméraires ou non rationalisées des utilisateurs, intervenant hors périmètre ou tardivement (ex : CA Douai, 22 juin 2023, n° 21/03807).
- Prestations de cadrage préalable
Les prestations de cadrage préalable sont particulièrement préconisées lorsque les besoins sont encore insuffisamment définis ou si le prestataire a besoin de mieux auditer le système du client sur lequel il doit intervenir, ou les logiciels tiers avec lesquels sa solution doit s’interfacer. Ces cadrages doivent être bien compris par les deux parties, dans la mesure où leur résultat redéfinit souvent le périmètre du projet et donc le périmètre final de l’engagement du prestataire (ex : CA Versailles, 29 févr. 2024, n° 22/02592).
- Modèles de contrats informatiques
En toute hypothèse, il est recommandé aux entreprises dont les besoins sont significatifs de disposer de modèles de contrats informatiques rédigés pour traduire leurs exigences, et de les décliner selon les services à acquérir (intégration de projet, souscription à des services cloud, hébergement de données ou d’applications, assistance technique…).
Ce sont ces contrats qui vont adresser les problématiques propres à chaque type de service, dont les suivantes :
Définition du périmètre des prestations
Le préambule du contrat doit permettre de rappeler les objectifs de l’entreprise, les enjeux qu’elle poursuit en recourant à la solution informatique ou au service cloud objet de la commande, car en cas d’échec, ce sont ces enjeux qui sont contrariés, ce qui peut avoir une grande importance en cas de litige ultérieur.
L’objet du contrat doit permettre de définir clairement le périmètre des prestations commandées, sans forcément dépendre uniquement de la teneur de la proposition du prestataire. C’est cet objet qui délimite l’engagement du fournisseur, et donc sa responsabilité en cas d’échec ou de dérive (calendaire ou budgétaire).
Clauses de recette et vérification de conformité
Dans le cas des contrats de projet, on doit entrer dans le détail de son déroulement, en indiquant les différents lots et les phases successives du projet (cadrage initial, conception générale et détaillée, réalisation des paramétrages, développements spécifiques…) jusqu’aux étapes cruciales de la recette et de la mise en production.
Les clauses de recette sont particulièrement critiques, car elles doivent permettre de contrôler que ce qui est livré correspond à ce qui a été commandé, et plus précisément, aux besoins fonctionnels et contraintes techniques exprimés dans le cahier des charges. Mais pas seulement, car les phases de cadrage et de conception sont souvent le théâtre d’évolutions, de difficultés ou d’interprétations qui sont particulièrement délicates à gérer. Si le contrat n’a pas prévu les modalités de gestion de ces écarts, la recette se passera forcément mal.
Il s’agit ici d’encadrer soigneusement l’obligation de délivrance conforme, qui caractérise les contrats de projets informatiques, et qui est l’objet de nombreux débats devant les juges en fonction de ce à quoi s’était contractuellement engagé le professionnel, et en fonction des décisions du client lui-même. A cet égard, la mise en production d’une solution pourtant imparfaite ne va pas sans conséquences sur l’acquisition de la recette (ex : CA Nîmes, 17 nov. 2023, n° 22/00107 ; CA Rennes, 12 déc. 2023, n° 22/00275 ou encore CA Douai, 18 janv. 2024, n° 22/00994).
On distingue souvent la « vérification d’aptitude au bon fonctionnement », sorte de recette « à blanc » permettant de vérifier que les fonctionnalités répondent aux besoins, et la « vérification de service régulier », qui permet de contrôler le bon fonctionnement de la solution en production avec l’ensemble des données chargées et des utilisateurs connectés.
Cette vérification de conformité s’effectue très différemment selon la méthodologie du projet. Dans les projets dits « en cycle V », le client doit d’abord vérifier que les spécifications préparées par l’intégrateur correspondent à ses besoins fonctionnels, puis que la solution livrée répond en tous points aux spécifications validées. Dans les projets plus « agiles », les utilisateurs contrôlent en temps réel que le comportement de la solution, construite par incréments successifs, correspond aux cas d’usage définis progressivement. Là encore, le contrat doit refléter fidèlement la façon dont le projet est mené concrètement.
Droits d’utilisation et métriques de contrôle
Dans les contrats informatiques de services récurrents en revanche, la recette ne revêt pas la même importance. Si elle doit être menée lorsqu’on adapte à la marge un service cloud aux besoins spécifiques du client, ce sont plutôt les niveaux de service qui importent ici : la disponibilité promise est-elle au rendez-vous ? Les temps de réponse satisfont-ils les utilisateurs ?
Dans tous les cas, la notion de « référentiel de conformité » est très importante, et doit avoir reçu une définition contractuelle d’un commun accord pour éviter les divergences d’interprétation et donc les risques de litiges.
Le contrat doit également encadrer les droits d’utilisation de la solution, du progiciel ou du service applicatif fourni. Cette question épineuse rejoint souvent les négociations financières, et le contrat doit clairement indiquer quelles sont les métriques permettant de mesurer l’utilisation qui est faite de la solution (nombre d’utilisateurs ? nombre de transactions ? volumétrie de données ? etc.).
Une attention toute particulière doit être apportée aux clauses sur les contrôles que l’éditeur d’un logiciel ou d’un service SaaS peut faire du respect des métriques, car plus d’un client a eu la mauvaise surprise de recevoir des facturations colossales pour des utilisations excessives qu’ils n’ont pas anticipées. On doit traquer ici les clauses léonines et s’assurer que le fournisseur ne décide pas seul de ce que sont les dépassements.
Modalités de paiement et révision des prix
Le contrat fait-il l’objet d’un prix forfaitaire, d’un prix variable, d’une simple estimation, ou d’un abonnement récurrent ? Il est capital de comprendre la nature du service et de s’entendre sur la nature du prix convenu, car les dépassements sont fréquents et le contrat doit permettre d’éviter les conflits en stipulant clairement les modalités d’appréhension de tels dépassements, de leur prise en charge selon la partie qui en est responsable, et les modalités de paiement (échéancier par étapes, fréquence d’un abonnement, terme échu ou à échoir, etc.).
Toujours au titre des prix, les contrats informatiques de services récurrents mentionnent généralement les modalités de révision des prix. Rappelons que ces révisions ne doivent pas être laissés à la discrétion du fournisseur, mais faire l’objet d’une détermination par référence à un indice général tiers, le plus souvent l’indice Syntec. Les négociations sont parfois difficiles, sur ce point, avec les éditeurs étrangers qui préfèrent garder une forte marge de manœuvre sur ce point.
De plus en plus, se pose la question des modifications budgétaires à l’occasion des changements du modèle économique du fournisseur. Souvent, un éditeur qui commercialisait ses progiciels sous forme de licences décide de basculer son parc de clientèle vers un service applicatif en cloud, ce qui modifie radicalement le contexte contractuel, et crée des difficultés insurmontables pour certains clients en situation de dépendance technologique, qui sont alors à la merci des changements de politique industrielle (et tarifaire) du fournisseur, que cela soit pendant le contrat ou à son échéance.
Si la jurisprudence montre que le client peut faire respecter les stipulations du contrat jusqu’à son terme, voire en prolonger un temps les effets pour éviter de graves dommages (ex : CA Paris 31 mars 2021, n°21/02172), il en va très différemment lorsqu’une nouvelle négociation doit avoir lieu après la fin du contrat, car l’éditeur a toute latitude pour imposer ses nouveaux tarifs. Ces points devraient absolument être appréhendés dans les contrats informatiques d’abonnements récurrents.
Propriété intellectuelle dans les contrats informatiques
Par ailleurs, la propriété intellectuelle est un sujet classique, chaque partie devant veiller à rappeler de quoi elle demeure propriétaire (le client, de ses données et de son système d’information ; le prestataire, de ses progiciels et de ses outils de travail).
En particulier, on doit savoir distinguer ici le régime d’éventuels développements spécifiques commandés pour personnaliser une solution, d’une part, et le régime des droits d’utilisation des progiciels standards ou des services cloud, d’autre part. Il est parfois contre-productif d’exiger par principe la cession en pleine propriété des développements spécifiques, alors qu’il peut être plus intéressant de permettre au fournisseur de les conserver, qui en assurera la maintenance dans le temps tout en permettant une modération des prix.
Clauses de garantie de non-contrefaçon
Dans tous les cas, une attention particulière doit être apportée aux clauses de garantie de non-contrefaçon, que certains éditeurs limitent trop (en particulier lorsqu’il s’agit d’éditeurs étrangers qui ne s’estiment pas soumis à la garantie légale d’éviction du droit français). Cette garantie de jouissance paisible est à mettre en place, qu’il s’agisse d’ailleurs de développer une solution spécifique, ou d’utiliser un progiciel ou un service applicatif standard.
Types de maintenance et engagements de service
La maintenance est un autre grand sujet crucial des projets informatiques. On doit savoir distinguer les différents types de maintenance (préventive, corrective, évolutive), et leur objet (les fonctionnalités logicielles, l’infrastructure d’hébergement…). La maintenance doit correspondre à des engagements de service, lesquels doivent être assortis de pénalités pour ne pas demeurer de simples pétitions de principes.
Les discussions sur les pénalités liées aux niveaux de services ont souvent très accrochées, car elles ont un impact sur le revenu du prestataire. Trop lourdes, les pénalités déséquilibrent le contrat (alors qu’elles ne constituent pas en soi la solution aux dysfonctionnements). Trop légères, elles n’ont pas d’effet comminatoire et ne sont qu’une profession de foi.
Protection des données personnelles et RGPD
Dès lors que la solution ou le service applicatif permet le traitement de données à caractère personnel pour le compte du client, on doit considérer le prestataire comme son sous-traitant au sens du Règlement européen de protection des données personnelles (RGPD). Le contrat doit alors comporter l’ensemble des engagements du prestataire relatifs à la protection des données et au respect de la réglementation applicable. Ces engagements sont nombreux, précis, et font souvent l’objet d’âpres discussions qui impliquent de connaître la réglementation et de bien comprendre la nature et le contour des services en cause.
En particulier, ces discussions ont acquis une très grande complexité lorsque le fournisseur n’est pas européen (et notamment s’il est américain). Le fait de lui confier des données à caractère personnel déclenche des transferts internationaux de données, qu’il est difficile d’encadrer efficacement sans pousser très loin la réflexion et les discussions consacrées à l’encadrement de ces flux de données.
Engagements de moyens et de résultats
Par ailleurs, qu’il s’agisse de la gestion de contrats informatiques de projets ou de contrats de services récurrents, l’intensité de l’engagement du prestataire doit être discutée. S’agira-t-il d’un engagement de moyens, parce que le résultat de la prestation est soumis à des aléas externes ou à une très forte implication du client ? S’agira-t-il d’un engagement de résultat exigé par le client compte tenu de la criticité du service et du fait qu’il n’en contrôle pas la bonne exécution ? Il est très important de savoir déterminer, de manière raisonnable et consensuelle, ce qui doit relever de l’une ou de l’autre de ces obligations.
Calendrier du projet et responsabilité contractuelle
De même, le calendrier du projet est-il impératif ou simplement prévisionnel ? En fonction des besoins du client, il est très important de le stipuler (ex : CA Versailles, 26 juillet 2022, n° 21/03036, ou CA Riom, 8 nov. 2023, n° 22/00010).
De manière générale, les négociations contractuelles sont bien entendu abondamment consacrées à l’encadrement de la responsabilité contractuelle des parties, et singulièrement celle du fournisseur en cas de manquement à ses engagements. Ces négociations sont parfois très conflictuelles car il s’agit de trouver un point d’équilibre entre l’indemnisation des préjudices du client en cas d’échec du projet informatique ou de dysfonctionnement du service fourni, d’une part, et la rentabilité du contrat pour le prestataire (qui ne peut pas être vu comme un « assureur » du client) d’autre part.
Les sujets débattus autour de la responsabilité contractuelle (articulation avec les pénalités, plafonds d’indemnisation, prise en charge des dommages directs ou indirects, perte des données, préjudice salarial, plafonds d’indemnisation, cas d’exclusion des plafonds d’indemnisation, cas d’exclusion de responsabilité entre professionnels, conséquences de la résolution du contrat en fonction du moment où elle se produit, charge de la preuve, etc.) sont nombreux et impliquent de recourir à des expertises poussées, au fait des dernières évolutions jurisprudentielles en la matière.
Clauses de résolution et réversibilité
Le projet informatique est un projet très important pour l’entreprise, et conditionne son bon fonctionnement : les conséquences d’un échec sont donc potentiellement catastrophiques pour elle, comme l’ont montré certaines affaires retentissantes. Il est crucial que les clauses de gestion de la responsabilité contractuelle soient pensées à l’aune de ces conséquences possibles, tout en restant acceptables par un prestataire qui doit veiller quant à lui à son équilibre économique. Les jurisprudences Chronopost et Faurecia continuent de peser dans le cadre des contentieux, et ce qui a été rédigé dans le contrat est particulièrement important dans ce contexte (ex : CA Paris, 22 mars 2024, n° 21/16505).
Les clauses de résolution du contrat sont également un point important à ne surtout pas négliger : quelles sont les causes qui peuvent mener à cette résolution ? Quelle est la procédure à respecter pour mettre en demeure la partie défaillante ? Et surtout, quelles seront les conséquences de la rupture du contrat ? S’agit-il de résoudre un contrat de projet qui ne sera donc pas achevé, laissant l’entreprise au milieu du gué avec des paiements versés sans contrepartie utile ? Ou s’agit-il de résilier pour l’avenir un contrat récurrent qui n’apporte plus satisfaction ? Là encore, une bonne connaissance des règles juridiques et une rédaction équilibrée des clauses sont indispensables.
En outre, la résolution du contrat doit être justifiée sur des manquements significatifs (ex : CA Paris, 26 mai 2023, n° 21/21311), et ne doit pas être prononcée à la légère, ni trop tôt… ni trop tard. Il est d’ailleurs possible, comme le permet l’article 1225 du Code civil, d’énumérer à la clause résolutoire les manquements significatifs qui ouvriraient droit à prononcer la résolution pour faute.
Conséquences de la rupture du contrat, la réversibilité est une question capitale. Le client doit absolument pouvoir faire reprendre par un tiers le contrat de projet qui s’arrête avant terme, afin de ne pas totalement perdre les investissements qu’il a exposés pendant les mois, parfois les années précédentes, et espérer parvenir à une mise en production prochaine. De même, le client doit absolument pouvoir basculer d’un service récurrent à un autre, d’où des exigences de portabilité et de réversibilité qu’il convient de porter dans la gestion de contrats informatiques. Il est souvent préférable d’organiser la sortie anticipée d’un contrat qui est devenu néfaste pour les deux parties, plutôt que de persévérer dans un effort dommageable aux deux parties.
Importance de la réversibilité dans la gestion de contrats informatiques
La réversibilité répond à l’exigence d’autonomie du client, qui ne peut être lié malgré lui à un prestataire qui ne lui donne pas satisfaction. Sur ce point, le contrat ne devrait pas se borner à stipuler une clause générique, mais entrer dans le détail de ce qu’impliquera réellement la réversibilité. A titre d’exemple, il ne sert à rien de stipuler une réversibilité d’une durée standard de trois mois, quand en réalité, l’empreinte technologique de l’éditeur chez le client est telle que ce dernier ne saurait migrer vers une alternative en moins de dix-huit mois !
Sécurité des données et exigences dans la gestion de contrats informatiques
En matière de gestion de contrats informatiques de technologies, la sécurité des données et des actifs du client est un point essentiel. On en veut pour preuve l’inflation des textes législatifs, y compris au niveau européen, qui renforcent aujourd’hui les exigences que doivent porter les entreprises dans leurs contrats informatiques avec les fournisseurs, qu’il s’agisse de développer une solution spécifique ou plus encore de recourir à un service cloud. Les clauses du contrat doivent donner force aux exigences de sécurité du client, qui peut s’inspirer en cela des préconisations de l’ANSSI, voire exiger des certifications (de type ISO27001 ou SecNumCloud).
Sauvegarde des données et plans de continuité d’activité
La sécurité est une question particulièrement ardue, notamment en cas de recours à un cloud provider (qui définit alors unilatéralement les modalités de protection des actifs que lui confie son client, charge à ce dernier de vérifier que ces modalités lui conviennent), ou encore en cas d’infogérance (car selon les configurations, la sécurité implique une distribution des rôles entre le prestataire et le client, en particulier lorsque l’activité du client du client entraîne des exigences sectorielles liées, par exemple, à l’hébergement de données de santé, à l’administration de systèmes hautement critiques, ou au traitement de données bancaires).
La sécurité implique également de se soucier de la sauvegarde périodique des données, et de la redondance du système afin d’éviter qu’un sinistre, toujours possible, ne prive l’entreprise de ses ressources externalisées sans solution de secours. Les projets les plus complexes ainsi que les services applicatifs critiques impliquent donc de s’interroger sur la pertinence des plans de continuité d’activité qui doivent être le fruit d’une réflexion conjointe des parties.
Précautions supplémentaires dans les contrats de projets
Les contrats de projets doivent comporter d’autres précautions encore, notamment contre le prêt de main d’œuvre illicite lorsque le personnel du prestataire intervient directement auprès du client (comme c’est nécessairement le cas pour analyser ses besoins et paramétrer la solution mise en œuvre), la lutte contre la corruption, la responsabilité sociale et environnementale, la gestion des déchets électroniques, ou encore les restrictions à l’exportation des technologies, toutes clauses qui prêtent parfois à des discussions difficiles selon le contexte de l’entreprise ou la nationalité du fournisseur.
Suivi de l’exécution et gestion de crise dans la gestion de contrats informatiques
Enfin, même si le rôle du contrat est de définir les engagements respectifs et de prévenir les difficultés, il ne peut suffire à toutes les résoudre. Plus le contrat est complexe, et en tous cas plus le contrat porte sur une ressource stratégique de l’entreprise, plus il est nécessaire d’assurer le suivi de son exécution, non seulement au travers d’une gouvernance opérationnelle (comités de pilotage et de suivi), mais aussi au travers d’une prestation de « contract management » afin de vérifier le respect des engagements tout au long de son exécution, et de mettre en œuvre les procédures de gestion de crise en temps utiles, s’il y a lieu.
*
On le voit, la rédaction et la négociation des contrats informatiques ou de services numériques impliquent de s’appuyer sur des expertises précises, et de savoir rédiger des clauses équilibrées qui permettront de protéger les intérêts bien compris de chaque partie. Ces négociations sont complexes, et leur nature varie très largement selon par exemple que l’entreprise discute avec une SSII locale soucieuse d’un accompagnement personnalisé, avec un intégrateur national rompu à l’exercice des négociations, ou avec un cloud provider international qui propose un service très largement standardisé. Il y a pourtant, dans tous les cas, des clauses capitales qu’on doit savoir rédiger et négocier, pour éviter les conséquences d’un échec ou d’un dysfonctionnement rédhibitoire du système, car la chronique des litiges informatiques est peuplée d’exemples d’accidents industriels qu’un mauvais contrat n’a malheureusement su ni anticiper, ni indemniser.
Le département PITD de DS Avocats propose une large gamme d’accompagnements à la contractualisation des projets informatiques et des services numériques, qu’il s’agisse d’accompagner les entreprises qui font l’acquisition de telles solutions et prestations, ou les fournisseurs professionnels qui proposent leurs services sur le marché.
Avocat Counsel
DS Avocats
