Définition, contractualisation et assurance qualité des conditions posées

1 Contractualiser les conditionnalités 

Ce chapitre identifie les éléments clés de la contractualisation, la relation résultant d'un processus d’approvisionnement. Chaque section aborde un sujet faisant l'objet d'une ou plusieurs clauses contractuelles, en précisant les raisons pour lesquelles ce sujet peut être abordé et son impact potentiel sur l'exécution du contrat. 

1.1 Clause de quatre coins : exclusion des conditions générales 

En matière de contractualisation, il est important de bien comprendre ce qui constitue (ou fait partie) de la documentation contractuelle. La clause dite de « quatre coins » garantit que tout ce qui a trait à la relation contractuelle doit être expressément inclus dans l'ensemble des documents que les parties acceptent de considérer comme le contrat entre elles. Aucune condition ne peut s'appliquer (hormis celles prévues par la loi) autre que celles convenues par écrit. 

Souvent explicitement incluse, la conséquence la plus importante de cette clause est que les conditions générales divergentes d’une partie, telles que celles que nous trouvons généralement au dos des factures ou jointes à une offre, ne s’appliquent pas dans le cadre de la relation contractuelle. 

Comme toujours, les problèmes résident dans les détails. Il est particulièrement judicieux d'autoriser l'inclusion de documents distincts uniquement par référence, notamment dans les contextes contractuels complexes. Cela facilite la référence aux normes du secteur, par exemple, mais l'autorité contractante doit être vigilante lorsqu'elle accepte des références aux documents du fournisseur. 

De plus, il est essentiel que l'AC fasse preuve de prudence lorsqu'une solution peut nécessiter l'acquisition du droit d'utilisation des droits de propriété intellectuelle (DPI) d'un tiers. Une telle licence, si elle n'est pas obtenue par l'intermédiaire du fournisseur et dans les limites de la relation contractuelle avec ce dernier, nécessite inévitablement un accord contractuel distinct avec le titulaire des DPI concernés. Les termes de l'accord avec le fournisseur ne régissent pas un tel accord. La clause de quatre coins ne s'appliquera pas non plus et l'AC pourrait se retrouver coincée dans un bourbier de conditions générales du concédant, comme celle qu'elle cherchait à éviter par cette clause. 

1.2 Principales responsabilités de l'acheteur 

Énumérer les principales responsabilités de l'AC est utile, car cela permet de délimiter clairement ces fonctions. En détaillant minutieusement les obligations de l'AC et en intégrant une formulation qualifiant sans équivoque cette liste de restrictive, les AC peuvent prévenir les litiges lors de l'exécution concernant le partage des responsabilités. 

Ceci est particulièrement important dans les accords complexes où une forte interdépendance existe entre les parties. Cette interdépendance ne doit jamais justifier l'inexécution. Si l'AC est responsable de l'exécution d'une action particulière, le contrat doit prévoir que cette action soit déclenchée par une demande écrite du fournisseur.

1.3 Principales responsabilités des fournisseurs 

Tout comme il est logique d'énumérer les obligations des AC, il est judicieux d'énumérer celles du fournisseur. La liste de ces obligations devrait toutefois être différente. Lorsqu'un contrat en technologie vise généralement un résultat (c'est-à-dire une solution à développer et à mettre en œuvre), la liste des obligations ne peut être limitative. Il incombe au fournisseur d'atteindre un résultat en s'acquittant des tâches énumérées dans une liste, ainsi que de tout ce qui découle de l'obligation générale de fournir le résultat souhaité. 

La liste des obligations des fournisseurs vise donc à garantir que certaines obligations spécifiques ne soient pas négligées plutôt qu’à offrir un aperçu exhaustif. 

1.4 Facturation et paiement 

Lors de la définition des conditions de facturation et de paiement, plusieurs sujets requièrent l'attention de l'AC. 

Premièrement, la clause doit clairement définir les conditions dans lesquelles le fournisseur est autorisé à facturer à l'AC. La question se pose de savoir quel est le déclencheur du droit de facturer. S'agit-il du simple écoulement du temps, dans le cadre d'un contrat de licence, ou de l'acceptation par l'AC des travaux effectués par exemple ? Des liens vers les clauses contractuelles relatives à l'acceptation peuvent être intégrés ici afin de garantir que les parties connaissent les conditions de soumission et de paiement d'une facture. 

Dans le cas d'une licence ou d'un abonnement nécessitant le paiement répété de frais, il est important de préciser si les paiements seront effectués avant ou après la période couverte. En particulier lorsque ces paiements concernant une annuité, la différence entre les deux peut être conséquente. 

La clause doit définir les informations devant figurer dans la facture et le format utilisé, en définissant si une facturation électronique doit être utilisée par exemple. 

La clause définira un délai de paiement et pourra inclure un délai de vérification, c'est-à-dire un délai permettant à l'AC d'évaluer l'exactitude de la facture. 

La clause peut également prévoir les conditions de révision des prix, la formule à appliquer et les références de prix à utiliser dans la formule. 

Enfin, il est essentiel de préciser dans le contrat que toute facturation sera effectuée par voie électronique, dans le respect des normes PEPPOL (Pan-European Public Procurement Online ou approvisionnement public paneuropéen en ligne).39, car cela est obligatoire pour les marchés publics. 

1.5 Droits de propriété intellectuelle (DPI) 

Il n'existe guère de relation contractuelle portant sur la technologie qui n'implique pas, dans une certaine mesure, l'attribution de droits de propriété intellectuelle. Les DPI constituent l'élément majeur de la relation économique dans les contrats dans l’industrie de la technologie. 

Compte tenu de la multiplicité des relations autour de la propriété intellectuelle, il est fortement conseillé d’aborder expressément la question. 

Ce faisant, les autorités contractantes doivent s'efforcer de réserver des droits suffisants aux fins poursuivies, tout en s'abstenant de toute revendication excessive qui n'apporte aucune valeur ajoutée réelle mais augmente les coûts et/ou réduit la volonté des fournisseurs de proposer des services. Cette section vise à fournir quelques orientations. 

1.5.1 Définition du cadre des DPI 

Lorsqu'une relation contractuelle implique (i) le développement de matériel et/ou de logiciels, (ii) l'utilisation de logiciels et/ou de données, ou (iii) l'accès à des services XaaS destinés au stockage et/ou à la création de données, des dispositions relatives à la propriété intellectuelle sont requises. Lors de la rédaction de ces accords contractuels, il est courant de distinguer les « informations de base » des « informations de premier plan », les informations de base étant celles qui existent avant l'exécution du contrat et/ou qui sont développées indépendamment de celui-ci. En revanche, les informations de premier plan sont celles qui résultent de l'exécution du contrat. Une autre distinction est établie sur base de l'origine : les informations peuvent provenir du fournisseur, de l'AC ou des deux40. 

Concernant les informations de l'historique, le système par défaut prévoit que la propriété reste celle du propriétaire initial : les informations de l'historique du fournisseur restent la propriété de ce dernier, tandis que les informations de l'historique détenues par l'AC restent la propriété de l'AC. Si l'AC doit utiliser les informations d'historique du fournisseur, cette utilisation impliquera des accords de droit d'utilisation. 

La propriété des informations de premier plan doit être établie dans le contrat, car il s’agit d’informations créées à la suite de l’exécution du contrat. 

Les accords contractuels relatifs aux informations de premier plan prévoient l’attribution de droits de propriété et l’octroi de droits d’utilisation conformément aux besoins prévus dans le contrat. 

1.5.2 Rédiger une position appropriée sur les DPI 

Pour l'AC, il est essentiel de s'assurer que le contrat lui attribue des droits (et aux utilisateurs, aux autres prestataires, etc., le cas échéant) permettant toutes les utilisations prévues lors de l'appel d'offres. Parallèlement, l'AC doit s'abstenir de demander plus que nécessaire, car l'acquisition de droits superflus et qui ne seront jamais nécessaires est trop coûteuse. 

Une clause de DPI simple pourrait être structurée comme suit : 

• Conservation de la propriété intellectuelle sur les informations de base par le propriétaire initial
• Attribution de la propriété intellectuelle aux informations de premier plan
• Octroi des droits d'utilisation nécessaires 

Bien que la logique de traiter la question selon cette approche soit séduisante, il convient de garder à l'esprit que l'objet du contrat peut impliquer le développement et la mise en œuvre d'une application, cette dernière étant une combinaison d'informations de base du fournisseur et/ou de tiers, associées à des informations de premier plan créées par le fournisseur. Dans un tel contexte, une clause de propriété intellectuelle typique peut inclure l'attribution de la propriété des informations de premier plan développées selon les termes du contrat, ainsi qu'un droit d'utilisation des informations de base du fournisseur, permettant à l'AC d'utiliser pleinement et sans restriction l'application telle que développée. 

Les fournisseurs seront réticents à céder la propriété des informations de base à une autorité de certification, car ces informations sont généralement constituées de blocs de construction et de morceaux de code qu'ils ont déjà utilisés et souhaitent réutiliser dans d'autres projets. Par conséquent, une autorité de certification souhaitant obtenir la pleine propriété du développement peut se heurter à des fournisseurs réticents à conclure un contrat ou à un prix plus élevé. À moins que l'autorité de certification cherche à commercialiser la solution développée par le fournisseur et acquise dans le cadre du contrat, la pleine propriété du code n'est généralement pas requise. 

Quant aux droits d’utilisation à accorder, les autorités contractantes doivent réfléchir à ce qu’elles désirent en faire. 

Si un tiers doit utiliser l'application, l'AC doit prévoir le droit de sous-licencier ce droit. Ceci est également significatif pour le soutien et la maintenance futurs de l'application. En particulier dans le cadre d'un marché public, un appel d'offres pour un support continu ne doit pas être limité par l'absence de droit d'intervention de tiers. La notion d'« utilisation » doit être claire quant aux limitations imposées. Existe-t-il une limitation du nombre d'utilisateurs ? De la quantité de données ? De telles limitations sont rares si l'accord implique un développement personnalisé, mais l'AC doit le garantir. 

1.5.3 L'utilisation d'applications de plateforme 

Une situation particulière se produit lorsque la solution proposée est élaborée autour d'une application de plate-forme, c'est-à-dire un environnement logiciel préconstruit, généralement basé sur le cloud, qui fournit des fonctionnalités pouvant être intégrées par un fournisseur dans le cadre d'une solution personnalisée. 

L'utilisation de ces applications de plateforme nécessite une licence distincte, limitée dans le temps, pour exploiter les applications intégrées à la solution personnalisée. Cela signifie que l'AC doit non seulement financer le développement et un droit d'utilisation perpétuel, mais aussi s'acquitter de frais de licence réguliers. 

L'utilisation de telles applications de plateforme présente des avantages évidents. Le temps de développement est généralement plus court et le coût initial est moindre. La puissance de ces applications de plateforme et la multitude de fonctionnalités qu'elles offrent sont considérables. 

Les inconvénients sont toutefois tout aussi évidents et, lorsqu’elle autorise les applications de plate-forme à faire partie de la solution souhaitée, l’autorité de certification doit être vigilante. 

Tout d'abord, se pose la question des conditions générales d'utilisation de ces applications, dont le contenu et la variabilité sont très difficiles à concilier de concert avec le droit des marchés publics. Une solution consiste à confier la relation contractuelle relative à l'application plateforme au fournisseur, ce dernier sert alors d'intermédiaire entre l'AC et le fournisseur de l'application de plateforme, soustrayant l'AC aux conditions de licence de ce dernier et lui accordant un droit ultérieur d'utilisation de l'application de plateforme intégrée à la solution développée. 

Deuxièmement, il existe un risque quant au coût difficile à maîtriser : les frais de licence, les coûts de support, etc., peuvent augmenter au fil du temps, tandis que les nouvelles versions de l'application de plateforme offriront non seulement des fonctionnalités plus nombreuses et améliorées, mais nécessiteront également l'adaptation du logiciel personnalisé développé par le fournisseur autour de cette application. La résolution de cet inconvénient dépasse le cadre de cette ligne directrice, car elle implique des choix fondamentaux concernant la nature de la solution envisagée et le niveau acceptable de personnalisation spécifique à l'application de la plateforme. 

Troisièmement, il est évident que trouver une solution concernant une application de plateforme accroît le risque de dépendance vis-à-vis d'un fournisseur, car cela crée une dépendance secondaire. L'AC doit non seulement s'assurer que le fournisseur n'est pas le seul à pouvoir assurer le support et la maintenance de la solution, mais aussi chercher à mitiger la dépendance vis-à-vis de l'application de plateforme choisie. Des mesures visant à remédier à ce problème doivent figurer dans la partie de la livraison dans le contrat. 

1.6 Adhésion aux normes et aux pratiques de l'industrie et compatibilité 

L'AC doit s'assurer que le fournisseur respecte les normes et pratiques du secteur. Outre le fait que ces exigences sont souvent nécessaires pour garantir le bon fonctionnement et l'interaction de la solution souhaitée avec l'environnement, elles constituent un élément clé pour éviter la dépendance vis-à-vis d'un fournisseur. Si le respect des normes ne garantit pas la sortie de cette dépendance, le non-respect de ces normes garantira très probablement cette dépendance pour le fournisseur. 

Il est impératif que l’AC fasse ses devoirs le cas échéant et s’assure que la liste des normes auxquelles le fournisseur et la solution doivent se conformer est claire et exhaustive. 

La compatibilité est une exigence visant à garantir que la solution interagit avec l'environnement numérique déjà installé, lit et écrit les données dans le format choisi et, en examinant la compatibilité avec les applications existantes et largement utilisées, contribue à la portabilité des données résultantes. 

1.7 Responsabilité

1.7.1 Général 

Aucune clause contractuelle n'a fait l'objet de plus de débats et de négociations que la clause de responsabilité. Des termes comme « faute » et « responsabilité » ont une connotation morale qui semble parfois faire obstacle à un partage rationnel des risques, ce qui est précisément le cas. 

Il ne s'agit pas d'une clause de responsabilité, mais d'une clause limitative de responsabilité. La responsabilité contractuelle est inscrite dans le droit des contrats de l'UE et ne nécessite aucune clause pour s'appliquer à un contrat. Cependant, il est courant que les parties conviennent d'une limitation de cette responsabilité, tant en termes de portée que d'indemnisation. 

Bien qu'il soit de bonne pratique qu'une clause de limitation de responsabilité fonctionne dans les deux sens, la partie qui semble en bénéficier le plus est le vendeur, car dans la plupart des cas, les devoirs de l'AC ne se limitent guère au paiement des factures. 

La raison d’être du vendeur est de limiter l’exposition à la responsabilité à des montants prévisibles et limités, que les polices d’assurance peuvent facilement couvrir. 

La raison d'être de l'AC est de savoir dans quelle mesure le risque est absorbé par le vendeur et à quel coût (supplémentaire), de comprendre quel risque reste à la charge de l'AC et d'éviter ce qui reviendrait à assurer le même risque deux fois. 

1.7.2 Limitation de la portée 

Quelle est l'étendue du préjudice à indemniser en droit ? La pratique contractuelle internationale a conduit à une pratique limitant expressément la responsabilité contractuelle aux dommages directs, excluant une multitude d'« autres » dommages, issus principalement de la jurisprudence américaine, dont certains sont tout simplement dénués de sens en droit civil. 

Toutefois, le concept de base est clair : les parties conviennent qu’elles ne seront responsables l’une envers l’autre, en vertu du contrat, que des dommages qui sont une conséquence directe de la faute ou de l’omission commise. 

Un exemple peut illustrer ce point. Si un système de communication est installé pour couper les transformateurs en cas de panne du réseau électrique et que cette panne est imputable au fournisseur ayant installé ce système de communication, celui-ci est responsable des dommages directs, pouvant consister en l'explosion d'un transformateur. Ces dommages sont une conséquence directe et donc prévisible pour ce fournisseur. Avec une clause d'exclusion des dommages indirects (en supposant que le droit applicable prévoie une responsabilité pour les dommages indirects), le fournisseur ne sera pas responsable de la perte de production d'une usine voisine résultant de la panne d'électricité prolongée. 

Ce dernier dommage est une affaire entre la compagnie d'électricité et l'usine, et la répartition fait l'objet du contrat entre ces deux entités. 

1.7.3 Limitation du montant 

Les clauses de limitation de responsabilité limitent non seulement l'étendue des dommages, mais également le montant de l'indemnisation à verser. L'objectif est d'aligner le risque à couvrir sur la valeur du contrat. 

Prenons l'exemple précédent et imaginons que le fournisseur de systèmes de communication ait un contrat d'une valeur de cent mille euros par an. Si le risque à couvrir correspond à la valeur de transformateurs susceptibles d'exploser en cas de panne du système, la prime d'assurance correspondante pourrait être prohibitive, rendant ainsi le contrat économiquement non viable par exemple. 

Réduire l'exposition implique de baisser la prime d'assurance pour le fournisseur. Quant à l'entreprise d'électricité, elle devrait de toute façon disposer d'une couverture d'assurance pour son réseau. Ainsi, la part du risque transférée vers elle, en limitant l'indemnisation pouvant être obtenue du fournisseur, est probablement assurée moyennant une augmentation moindre de la prime d'assurance. 

Les limitations de l'indemnisation payable revêtent diverses formes. Sous sa forme la plus simple, il s'agit d'une clause stipulant que la responsabilité contractuelle est plafonnée à un montant X. Des variantes peuvent plafonner la responsabilité à un montant annuel ou combiner une limite annuelle et un plafond de responsabilité totale pour le contrat. Les montants peuvent être fixes ou exprimés en pourcentage des montants facturés et payés.41. 

1.7.4 Des limites aux limitations 

La plupart des clauses de responsabilité excluent l'applicabilité des limitations qu'elles prévoient en cas de négligence grave ou de faute intentionnelle. Plus que de se réconcilier avec l'aspect moral de la responsabilité pour faute, cette mention est nécessaire à la survie de la clause en tant que telle, car une clause limitant la responsabilité pour négligence grave ou faute intentionnelle sera frappée de nullité dans de nombreuses juridictions. 

Par souci de clarté, il est conseillé d'exclure expressément la clause d'exonération de responsabilité de la limitation de responsabilité. Pour plus d'informations sur la clause d'exonération de responsabilité, veuillez vous référer au chapitre 1.9. 

1.7.5 Capture de la limitation de responsabilité dans les documents d'appel d'offres 

L’avantage d’être un CA dans un processus d’approvisionnement est de tenir la plume et de prévoir les termes et conditions contractuels applicables. 

Il peut sembler paradoxal qu'un entrepreneur inclue une clause de limitation de responsabilité dans un document d'appel d'offres, mais il existe de nombreuses bonnes raisons de le faire. Plus importants encore, les participants à un appel d'offres calculent leurs prix en fonction des informations contenues dans le document d'appel d'offres. Si le risque posé par la responsabilité n'est pas mentionné dans ce document, ils doivent inclure une prime correspondante dans leur tarification. 

La rédaction de cette clause dans le dossier d'appel d'offres permet d'établir une position claire dès le départ et peut réduire le temps de négociation ainsi que les coûts. De plus, en cas de préoccupations particulières, la clause de responsabilité ainsi prévue peut être traduite de manière adéquate. 

1.8 Assurance 

Le corollaire d’une clause de responsabilité qui prend en compte l’assurance du risque de responsabilité est une clause d’assurance qui oblige le vendeur à souscrire l’assurance nécessaire proportionnelle à ce risque. 

La clause d'assurance imposera généralement au fournisseur l'obligation de mettre en place une assurance adéquate qui couvre un certain nombre de risques pas nécessairement liés à la responsabilité contractuelle envers l'AC42, et peut exiger du fournisseur qu'il fournisse la preuve de cette assurance en présentant les politiques à l'AC dès l'entrée en vigueur du contrat et/ou sur une base annuelle. 

1.9 Exonération 

La clause d’exonération de responsabilité protège les parties contre les effets d’une violation (entre autres) des DPI de tiers. 

Du point de vue de l'AC, la clause d'exonération de responsabilité vise à garantir l'utilisation sans perturbation de la solution fournie par le fournisseur. Si un tiers prétend que cette utilisation porte atteinte à ses DPI, la clause prévoit que le fournisseur peut intervenir et prendre la défense de l'AC. Si cette défense échoue, ou si le fournisseur choisit un règlement transactionnel, la clause lui impose l'obligation d'assurer l'utilisation sans perturbation de l'AC. Si toutes les mesures susmentionnées échouent, le fournisseur sera tenu de remédier à la violation et de fournir à l'AC une solution qui ne porte pas atteinte aux DPI du tiers. 

Du point de vue du vendeur, la clause réciproque les obligations énumérées ci-dessus lorsque la violation est causée par une utilisation non intentionnelle par l'AC ou par une utilisation dans une combinaison non divulguée, ce qui rend cette utilisation contrefaisante. 

La clause ne comporte pas de plafond ni de limite et il est important de garantir cela en l'excluant explicitement de toute limitation ou plafond prévu dans le contrat par exemple. 

Ce qui précède porte sur l'exonération de responsabilité en matière de DPI, mais comme indiqué précédemment, d'autres domaines d'application existent. Une exonération de responsabilité, pour des dettes fiscales, peut, dans certains contrats, être pertinente par exemple. Il est important de veiller à ce que la clause d'exonération de responsabilité soit rédigée de manière à ne pas être interprétée comme annulant implicitement toute clause d'exonération de responsabilité prévue par la loi. 

L'application de la clause d'exonération de responsabilité peut s'avérer problématique, car elle oblige la partie qui l'invoque à s’appuyer sur la bonne gestion de la réclamation par l'autre partie, à rechercher une assistance juridique adéquate et, si nécessaire, à mener des négociations efficaces en vue de l'obtention de la licence de tiers requise. Adopter une approche offrant davantage de contrôle à l'AC peut s'avérer judicieux, notamment lorsqu'une solution technique est probablement difficile à mettre en œuvre ou que la solution est cruciale. 

1.10 Modifications 

Dans les limites de ce qui est autorisé par la réglementation sur les marchés publics, il existe toujours la possibilité que les parties manifestent le besoin de modifier les termes du contrat pour obtenir le résultat souhaité. 

Ces changements peuvent être grossièrement divisés en deux catégories, à savoir les modifications des caractéristiques techniques d’une part et les modifications des termes du contrat d’autre part. 

L'adaptation des caractéristiques techniques en cours d'exécution d'un contrat est fréquente, car c'est lors de la création d'un produit fourni que des défauts apparaissent dans le concept initial ou que de meilleures approches pour atteindre le résultat souhaité émergent. Pour remédier à ces changements, souvent fréquents, il est judicieux de prévoir un processus de changement visant à une décision intégrée dans les procédures de gouvernance (veuillez vous référer à la partie ci-dessous). Ce processus permettra de déterminer comment une demande de changement est créée et transmise aux instances de gouvernance compétentes en vue d'une approbation mutuelle. 

La modification de la durée du contrat devrait être beaucoup moins fréquente et nécessitera un accord formel au niveau de gestion appropriée après la négociation portant sur le changement envisagé. 

L’initiation de la modification peut être réalisée sur base d’un processus similaire à celui ci-dessus, mais si et quand les parties acceptent la modification, celle-ci n’entrera en vigueur qu’après la signature d’une modification formelle. 

Comme indiqué précédemment, les lois sur les marchés publics restreignent les conditions de modification des contrats. La principale préoccupation en matière de marchés publics est de préserver l'égalité des conditions de concurrence entre les concurrents. Permettre à l'autorité compétente de s'écarter d'exigences auparavant considérées comme minimales ou de clauses ayant un impact crucial sur la relation contractuelle ouvrirait la voie à des pratiques où un assouplissement des clauses après l'attribution du marché confère un avantage indu au participant qui était en mesure d'anticiper ces changements.43. 

1.11 Expiration – Résiliation 

Cette clause régit la fin du contrat, soit par l'arrivée à son terme, soit par la résiliation véritable par consentement mutuel ou pour cause par l'une des parties, en détaillant les conditions d'une telle résiliation anticipée et en énumérant les obligations des parties pour chaque scénario de fin de contrat. 

1.12 Résolution des litiges 

Les clauses de résolution des litiges peuvent comprendre trois éléments : 

• Obligation pour les parties de rechercher une réconciliation avant de saisir le tribunal
• Un choix de loi
• Un choix de la structure compétente pour rendre un jugement 

Dans les contrats privés, cette clause a tendance à être utilisée par les parties pour poser un choix quant à la structure et conduit à un débat sur un lieu exotique qui sera le théâtre d'une éventuelle résolution de litige, en l’ajoutant aux les documents d'appel d'offres, cela sert à apporter de la clarté. 

1.12 1 Réconciliation 

Il n'est pas rare qu'une clause de règlement des litiges comporte l'obligation pour les parties de tenter de régler un litige par des discussions de bonne foi avant d'engager une procédure judiciaire. Une telle clause peut se limiter à établir le principe, sans plus de détails, de la procédure à suivre pour parvenir à un règlement à l'amiable. Cependant, il est judicieux de prévoir une procédure minimale, notamment pour les contrats technologiques complexes et de grande valeur. Cela peut supposer une définition de la communication déclenchant ces discussions de règlement à l'amiable, les modalités de réponse, la durée convenue de ces discussions, etc. 

Un élément utile pour définir le processus de règlement réside dans le recours aux mécanismes d'escalade prévus dans la gouvernance du contrat (veuillez vous référer à la partie ci-dessous). À mesure que le litige progresse dans son processus de gestion, il peut être examiné dans une perspective plus large, facilitant ainsi la recherche d'un règlement mutuellement acceptable.  

1.12.2 Choix de la loi applicable - tribunal compétent 

En indiquant clairement dans les documents d’appel d’offres que les lois de l’État dans lequel l’AC opère s’appliquent, l’AC élimine toute ambiguïté éventuelle sur la question, même lorsqu’il s’agit d’entités étrangères. 

De même, il est précisé que le tribunal compétent dans la juridiction où opère l'AC sera la structure compétente pour rendre un jugement en cas de litige devant le tribunal saisi et régler l'affaire, quelle que soit la juridiction où le vendeur est établi. 

1.13 Sécurité 

Les exigences de sécurité dans les contrats technologiques sont nécessaires pour assurer la conformité avec le cadre juridique en la matière44. 

En règle générale, une autorité de certification doit inclure des conditions relatives à l'authentification et au contrôle d'accès, à la protection des données, à l'intégrité du système et à la sécurité opérationnelle et de la chaîne d'approvisionnement qui garantissent un niveau de sécurité proportionnel à la pertinence de l'application et à son utilisation. 

La sécurité dès la conception doit être l’approche standard et le contrat doit contenir des dispositions permettant l’audit, l’inspection et le test des mesures de sécurité. 

La sécurité doit être intégrée aux SLA  et aux indicateurs de performances (Key Performance Indicators, KPI) afin que les performances dans ce domaine soient = étroitement surveillées. 

1.14 RGPD 

La mise en œuvre du règlement général sur la protection des données (UE) 2016/679 ajoute une dimension supplémentaire aux exigences globales de sécurité si une solution doit être utilisée pour le traitement des données personnelles. 

Bien que cette ligne directrice ne vise pas à développer les nombreuses implications du GCPR et la portée de son impact sur une AC, il existe un certain nombre de sujets qui doivent être abordés dans les documents d'appel d'offres pour garantir qu'un fonctionnement légal de la solution envisagée soit possible pour entamer le processus. 

1.14.1 Confidentialité dès la conception et par défaut 

Il va sans dire que l’obligation de mettre en œuvre des mesures techniques et organisationnelles garantissant les principes de protection des données doit être communiquée au développeur, car ces mesures techniques devront être mises en œuvre dans la solution. 

Il convient d'attirer l'attention sur l'approche « Fais le toi-même » (Do It Yourself, DIY) à laquelle les autorités de certification peuvent être confrontées lors de l'approvisionnement d'une solution basée sur une application de la plateforme. Cela signifie que le fournisseur d'applications de plateforme peut proposer une solution configurable pour un fonctionnement conforme, laissant au fournisseur – et bien souvent à l'autorité de certification – le soin de déterminer et d'appliquer les paramètres appropriés pour obtenir ce résultat. L'application de ces paramètres ou l'ajout des moyens de protection disponibles peut alors avoir un impact significatif sur l'utilisation, cette dernière n'étant généralement pas garantie par le fournisseur d'applications de plateforme. 

Par conséquent, parvenir à la confidentialité dès la conception et par défaut n’est pas simplement une question de contractualisation minutieuse de ce sujet, mais nécessite une coopération étroite avec des experts techniques pour faire correspondre le langage contractuel et les exigences techniques sur la conformité. 

1.14.2 Cryptage et contrôle d'accès : 

Une solution destinée au traitement de données personnelles nécessitera des protocoles de codage robustes pour les données en transit et aux attentes, ainsi que des contrôles d'accès basés sur les rôles. Ces éléments devront être décrits dans les exigences et, là encore, une collaboration avec des experts techniques sera nécessaire pour compléter les dispositions contractuelles. 

1.14.3 Transferts internationaux de données 

Un sujet spécifique qui nécessite une attention particulière concerne les restrictions imposées par le RGPD aux transferts internationaux de données, qui visent à garantir que les données personnelles ne soient pas transférées vers des juridictions offrant un niveau de protection inférieur. 

L'utilisation d'une solution sur le cloud peut prévoir un transfert international de données (personnelles), le cloud n'étant qu'une réalité abstraite de l'emplacement physique réel des serveurs. Si les serveurs du fournisseur de cloud sont situés hors de l'EEE (Espace économique européen), une AC doit vérifier l'existence d'une décision relative au caractère adéquat du niveau de protection de la Commission européenne confirmant que la protection des données dans ce pays est équivalente au niveau de protection offert par l'application du RGPD. Même si les serveurs sont physiquement situés au sein de l'EEE mais sous le contrôle d'une entité multinationale regroupant des entités à l'intérieur et à l'extérieur de l'EEE, le risque d'un transfert international est présent et des précautions doivent être prises.45. 

Des transferts internationaux de données peuvent également avoir lieu dans le cadre du support et de la maintenance de la solution. En particulier, lorsque le support de second niveau nécessite une reconstitution précise de la situation ayant donné lieu à un incident afin d'en déterminer la cause profonde, cette reconstitution peut impliquer une exposition aux données (personnelles) traitées au moment de l'incident. S’il est impossible d’exclure une telle situation, elle peut affecter la nature des services prévus par le contrat. En règle générale, un support « à la demande » peut constituer un problème, car il nécessite l'accès aux données par des opérateurs basés sur différents continents. 

1.14.4 Accord de traitement des données : 

A À n'importe quel stade de l'exécution du contrat, si le vendeur doit traiter des données personnelles, un accord de traitement des données (ATD ou Data Processing Agreement, DPA) doit être inclus en annexe au contrat46. 

1.15 Spécifications du service/produit 

Le contrat devra préciser ce que l'AC souhaite acheter. Il est important de définir les spécifications que le service ou le produit doit respecter. Généralement, dans les contrats propres à l’industrie de la technologie, cette clause renvoie aux annexes listant toutes les exigences (cf. infra). 

2. Contractualiser la performance de la livraison

2.1 Exigences de développement de logiciels  

Les sections suivantes sont essentielles à la gestion de l’exécution du contrat par le fournisseur. 

Les exigences de développement logiciel d'un contrat technologique définissent les attentes, les responsabilités et les produits fournis de l'AC et du fournisseur. Ces exigences comprennent généralement une description détaillée du périmètre des travaux, des fonctionnalités et des caractéristiques de la solution logicielle souhaitée, ainsi que des technologies spécifiques à utiliser. 

Les exigences de développement logiciel comprendront les performances, la compatibilité et la sécurité. 

Ces exigences peuvent faire l’objet d’une description plus détaillée si nous optons pour un type de développement en cascade, tandis qu'un chemin de développement agile fournit un plus haut niveau. 

2.2 Qualité de service 

Une annexe sur la qualité de service (Quality of service, QoS) décrit les normes de performance qu'un fournisseur doit respecter et les indicateurs utilisés pour mesurer cette performance. Elle garantit l'harmonisation des attentes entre le fournisseur et l'AC. 

2.3 Gestion de la prestation de services 

Un document de gestion de la prestation de services reflète les processus, la gouvernance et la supervision nécessaires pour garantir que les services décrits dans un contrat de service sont fournis de manière efficace et cohérente. Il établit des pratiques de gestion pour suivre, évaluer et améliorer la prestation de services. La gestion des incidents et des problèmes est communément définie dans la définition de la prestation de services. 

2.4 Procédure d'acceptation 

Tout produit fourni attendu par l’autorité contractante du fournisseur doit être accepté. Pour un produit technique, il est nécessaire de prévoir une documentation qui décrit le processus, notamment la détermination du type de tests requis pour l'acceptation, la procédure de réunion du fournisseur, de l'autorité contractante et, si nécessaire, de certains experts techniques pour les tests, les différentes étapes (la réception provisoire – la réception définitive), la procédure en cas d'échec des tests et les conséquences des différents résultats. 

2.5 Gouvernance 

Tout accord technologique qui nécessite une coopération prolongée entre une AC et un fournisseur bénéficie de l’ajout d’une annexe définissant une structure de gouvernance et des règles de participation à la gestion de cette relation durable. 

Traditionnellement, trois niveaux de gouvernance sont prévus : opérationnel, tactique et stratégique. Le niveau opérationnel gère généralement la gestion quotidienne, avec potentiellement plusieurs organes de gouvernance à ce niveau pour permettre une attention particulière aux détails opérationnels. Le niveau stratégique traite des sujets liés au projet ou au programme, notamment la revue périodique des SLA et des KPI, les demandes de changement et les émergences d'informations du niveau opérationnel. Le niveau stratégique réunit généralement un niveau de direction supérieur à celui du projet/programme et se réunit, à une fréquence relativement faible, pour discuter des sujets stratégiques liés au projet ou au programme, ainsi que des remontées d'informations du niveau tactique. 

La mise en place de ce type de structure permet aux parties de discuter des questions et de les aborder dans le cadre de la relation. 

2.6 SLA/KPI 

La performance d'un fournisseur dans le cadre d'un contrat de service est généralement mesurée au moyen d'accords de niveau de service (SLA) et/ou d'indicateurs clés de performance (KPI). Si le contrat envisagé comporte un volet de services étendus, l'ajout de SLA/KPI permettra à l'autorité contractante d'évaluer si la performance du fournisseur est conforme aux exigences contractuelles. 
Les SLA définissent les normes minimales acceptables en matière de performance des services. En revanche, les KPI sont des indicateurs mesurables capables d'évaluer l'efficacité et le rendement de la prestation de services. Le document peut répertorier autant de SLA que de KPI et évaluer la performance selon le processus de gouvernance établi. Des pénalités peuvent être appliquées en fonction des SLA et/ou des KPI. 

2.7 Plan de sortie / Transférabilité 

Prévoir un plan de sortie dans le cadre des accords contractuels constitue une mesure essentielle contre la dépendance vis-à-vis d'un fournisseur. Ce plan doit être disponible sous forme de schéma dès le départ. Le contrat doit exiger du fournisseur qu'il le mette à jour tout au long de sa durée de vie, de sorte qu'à l'expiration du contrat, un plan, avec les rôles et responsabilités, détermine la forme que doit prendre la sortie, les obligations restant à la charge du fournisseur pendant la phase de transition, ainsi que les produits fournis et le format à mettre à la disposition de l'autorité de certification et/ou du prestataire suivant. Le contrôle du plan de sortie doit être défini dans le cadre de la gouvernance.