Comprendre le droit des projets numériques à travers les contrats, les données, le cloud, la cybersécurité, le RGPD et l’intelligence artificielle

Article actualisé en septembre 2026

Une migration échoue.

Un ERP coûte finalement deux fois le budget prévu.

Un prestataire refuse de restituer une base de données parce que le contrat ne contient aucune clause de réversibilité.

Un utilisateur découvre qu'en modifiant une URL il peut consulter le dossier d'une autre personne.

Une entreprise subit une intrusion et plusieurs millions de données personnelles sont exfiltrées.

Une collectivité installe un algorithme derrière des caméras qu'elle est pourtant parfaitement autorisée à exploiter.

Dans chacun de ces cas, l'incident semble d'abord technique.

Pourtant, dès qu'un différend apparaît, les questions changent de nature.

Qui avait l'obligation de prévoir le risque ?

Qui devait informer l'autre partie ?

Le client avait-il correctement exprimé son besoin ?

Le prestataire devait-il le challenger ?

Une fonctionnalité non conforme constitue-t-elle une simple anomalie ou une inexécution contractuelle ?

Qui doit prouver qu'une information a été communiquée ?

Peut-on conserver une donnée simplement parce que le stockage ne coûte presque rien ?

Une entreprise peut-elle considérer que les données contenues dans son système lui appartiennent ?

Externaliser une plateforme dans le cloud permet-il d'externaliser la responsabilité juridique ?

Une autorisation de collecter des données implique-t-elle l'autorisation de leur appliquer un nouvel algorithme ?

Ces questions appartiennent au droit.

Mais elles concernent directement les architectes, développeurs, consultants, Data Engineers, Data Architects, DSI, RSSI, Product Owners et responsables Data.

L'objectif de cet article n'est donc pas de transformer un professionnel de l'IT en avocat.

Il est plus ambitieux sur un autre plan : construire une culture juridique de l'architecture numérique.

Pour y parvenir, nous allons apprendre à raisonner avec les concepts utilisés par les juristes : norme, obligation, responsabilité, faute, inexécution, préjudice, causalité, charge de la preuve, devoir d'information, devoir de conseil, obligation de moyens, obligation de résultat, résolution, réversibilité, responsable du traitement, sous-traitant, finalité, minimisation, accountability, privacy by design.

Puis nous allons observer comment ces concepts rencontrent des objets extrêmement concrets :

• une expression de besoin ;
• une architecture ;
• un devis ;
• un planning ;
• une recette ;
• une base de données ;
• un fichier d'export ;
• un historique ;
• un modèle de données ;
• un compte administrateur ;
• un VPN ;
• une politique IAM ;
• une API ;
• un journal technique ;
• un système de sauvegarde ;
• un algorithme ;
• une plateforme cloud.

La thèse centrale sera la suivante :

Dans un contentieux numérique, l'architecture technique devient progressivement une architecture de responsabilités.

1. Avant la jurisprudence : apprendre à lire le droit

Commençons par une erreur fréquente.

On entend régulièrement :

« La jurisprudence dit que... »

Cette formulation peut être correcte. Mais avant de l'utiliser, il faut comprendre ce qu'est réellement une jurisprudence et surtout ce qu'elle n'est pas.

1.1 La règle de droit et la décision de justice ne sont pas la même chose

Le droit applicable à un projet informatique peut provenir de plusieurs niveaux.

On trouve notamment :

• la Constitution ;
• le droit de l'Union européenne ;
• les lois ;
• les règlements ;
• les codes ;
• les contrats ;
• les décisions juridictionnelles ;
• certaines décisions d'autorités administratives indépendantes.

Dans le domaine Data, le RGPD constitue par exemple un règlement européen directement applicable.

Dans le domaine contractuel, une grande partie des mécanismes qui nous intéressent se trouve dans le Code civil.

L'article 1103 du Code civil formule l'un des principes fondamentaux du droit des contrats :

« Les contrats légalement formés tiennent lieu de loi à ceux qui les ont faits. »

Autrement dit, lorsque deux parties concluent valablement un contrat, elles doivent respecter les engagements qu'elles ont elles-mêmes définis.

Pour un projet IT, cela donne immédiatement une importance juridique considérable aux documents contractuels :

cahier des charges, spécifications, SLA, annexes techniques, exigences de sécurité, planning contractuel, procédures de recette, conditions de réversibilité, matrice de responsabilités, conditions de sauvegarde, engagements de disponibilité.

Ce ne sont plus simplement des documents projet.

Ils contribuent à déterminer ce qui était juridiquement dû.

2. Premier modèle mental : obligation, inexécution, préjudice, causalité

Lorsqu'un projet informatique tourne mal, quatre questions structurent une grande partie du raisonnement.

1. Quelle obligation existait ?

2. Cette obligation a-t-elle été exécutée correctement ?

3. Un préjudice existe-t-il ?

4. Existe-t-il un lien entre l'inexécution et ce préjudice ?

Cette séquence constitue un excellent modèle mental.

Prenons un exemple.

Une entreprise commande une plateforme Data.

Le contrat prévoit que les traitements quotidiens doivent être terminés avant 7 heures.

Après mise en production, les pipelines terminent régulièrement à 10 heures.

Le métier ne dispose donc plus des indicateurs nécessaires au démarrage de son activité.

Le raisonnement juridique peut devenir :

Obligation : disponibilité des données avant 7 heures.

Inexécution : pipelines terminant après l'heure contractuelle.

Préjudice : perturbation de l'activité, coûts supplémentaires, éventuellement perte économique.

Causalité : il faut démontrer que le préjudice invoqué résulte effectivement du retard.

Le droit commence ainsi à ressembler à un système de dépendances.

3. Force obligatoire et bonne foi : les deux piliers du contrat IT

L'article 1103 nous donne la force obligatoire.

L'article 1104 ajoute une autre idée fondamentale :

les contrats doivent être négociés, formés et exécutés de bonne foi.

Cette règle est d'ordre public.

Le terme ordre public mérite une explication.

Une règle d'ordre public est une règle à laquelle les parties ne peuvent pas librement déroger par contrat.

C'est une différence fondamentale entre :

règle supplétive, qui s'applique sauf volonté contraire ;

et

règle impérative ou d'ordre public, que le contrat ne peut neutraliser.

Dans le monde informatique, cela signifie que la liberté contractuelle est puissante, mais pas absolue.

4. Le contrat informatique ne contient pas toutes les obligations du prestataire

C'est ici que la jurisprudence devient passionnante.

Un raisonnement naïf consisterait à dire :

« Si ce n'est pas écrit dans le contrat, je ne le dois pas. »

Ce raisonnement est dangereux.

Pourquoi ?

Parce que certaines obligations peuvent résulter du droit applicable, de la nature de la relation ou de la qualité professionnelle des parties.

C'est notamment le cas du devoir de conseil du prestataire informatique.

5. Devoir d'information et devoir de conseil : ne pas les confondre

Les deux notions sont proches mais ne sont pas synonymes.

5.1 Le devoir précontractuel d'information

L'article 1112-1 du Code civil prévoit que la partie connaissant une information dont l'importance est déterminante pour le consentement de l'autre doit l'en informer lorsque cette dernière ignore légitimement cette information ou fait confiance à son cocontractant.

Il existe donc une logique informationnelle :

A sait quelque chose.

B ne le sait légitimement pas.

Cette information est déterminante.

A doit informer B.

Le texte précise même un mécanisme probatoire particulièrement intéressant.

Celui qui affirme qu'une information lui était due doit d'abord démontrer qu'elle devait lui être communiquée.

Ensuite, la partie qui devait l'information doit démontrer qu'elle l'a effectivement fournie.

Cette distinction devient fondamentale en projet.

Dire oralement :

« Je leur avais expliqué le risque »

est très différent de pouvoir produire :

• un compte rendu ;
• un email ;
• une présentation ;
• une réserve formalisée ;
• un ticket ;
• une décision d'architecture ;
• une acceptation explicite du risque.

La documentation projet devient donc également une documentation probatoire.

6. Le devoir de conseil va plus loin que la transmission d'une information

Informer signifie essentiellement transmettre une information pertinente.

Conseiller suppose une démarche plus active.

Le professionnel doit parfois :

• rechercher le besoin ;
• comprendre le contexte ;
• identifier les contraintes ;
• signaler les risques ;
• comparer des solutions ;
• attirer l'attention sur une inadéquation ;
• recommander une approche compatible avec l'objectif recherché.

La jurisprudence informatique française reconnaît depuis longtemps cette logique.

Dans un arrêt du 6 mai 2003, la chambre commerciale de la Cour de cassation valide le raisonnement selon lequel un prestataire informatique professionnel devait notamment s'intéresser aux besoins de son client et aux risques liés à leur insuffisante définition.

La présence d'un service informatique compétent chez le client ne supprimait pas automatiquement cette obligation, notamment parce que ce service ne possédait pas nécessairement l'expertise spécifique justifiant précisément le recours au prestataire externe.

Cette décision permet de comprendre un principe essentiel :

L'expertise du client ne neutralise pas mécaniquement l'expertise pour laquelle le prestataire a été engagé.

7. Le client averti : concept utile, mais souvent mal compris

Dans les contentieux IT, le prestataire peut tenter de soutenir :

« Mon client connaissait l'informatique. Il savait ce qu'il faisait. »

Juridiquement, la question devient celle du client averti.

Mais « averti » ne signifie pas simplement :

• posséder une DSI ;
• employer des développeurs ;
• avoir un architecte ;
• disposer d'une équipe Data.

Il faut regarder la compétence pertinente relativement au problème concerné.

Une banque peut posséder plusieurs milliers d'informaticiens et néanmoins recourir à un spécialiste externe précisément parce qu'elle ne possède pas une expertise suffisamment poussée sur une technologie donnée.

Le caractère averti est donc contextuel.

8. Une affaire de 2026 : le budget explose et le devoir de cadrage revient au centre

Une décision du tribunal de commerce de Chartres fournit une illustration particulièrement pédagogique.

Le projet avait initialement un budget de 32 368 euros HT.

Le montant facturé atteint ensuite 62 319,66 euros TTC.

Et un devis supplémentaire de 19 516 euros HT est encore proposé pour rendre le système opérationnel.

Le tribunal décrit une dérive budgétaire de 152 % et considère qu'elle révèle un manquement au devoir de cadrage et de conseil du prestataire.

Le prestataire invoquait notamment les compétences du client et l'intervention d'un autre conseil spécialisé.

Le tribunal ne considère pas cela comme suffisant pour supprimer son obligation de vérifier l'adéquation technique de la solution préconisée.

Pour un professionnel IT, cette affaire doit modifier la manière de regarder le cadrage.

Un cadrage n'est pas uniquement :

« comprendre ce que veut le métier ».

Il consiste également à construire une représentation suffisamment réaliste :

besoin → solution → complexité → charge → coût → risques → dépendances.

Une estimation complètement irréaliste peut donc devenir juridiquement pertinente.

9. Expression de besoin : document projet ou pièce juridique ?

Prenons une expression de besoin Data.

Elle contient :

• les sources ;
• les tables ;
• les colonnes ;
• les règles de transformation ;
• les règles de jointure ;
• les règles de qualité ;
• les cas nuls ;
• les fréquences ;
• les règles métier ;
• les SLA ;
• les restitutions attendues.

Pour l'architecte, c'est un document de conception.

Pour le juriste, il peut également contribuer à déterminer :

• ce qui a été demandé ;
• ce qui était connu ;
• ce qui était accepté ;
• la répartition des responsabilités ;
• la conformité de la livraison.

Cela conduit à une règle extrêmement pratique :

Plus une décision technique est structurante, plus sa traçabilité contractuelle et documentaire devient importante.

10. Obligation de moyens et obligation de résultat

Voici une distinction juridique qu'il faut absolument maîtriser.

Obligation de moyens

Le débiteur promet de mettre en œuvre les diligences appropriées pour atteindre un résultat.

Il ne garantit pas nécessairement que le résultat sera atteint.

Obligation de résultat

Le débiteur s'engage à obtenir un résultat déterminé.

Cette distinction influence notamment la manière dont l'inexécution sera caractérisée.

Mais il faut éviter une simplification fréquente :

« prestation informatique = obligation de moyens ».

C'est faux comme règle générale.

Un même contrat peut contenir plusieurs obligations de nature différente.

Par exemple :

Conseil d'architecture : logique souvent proche d'une obligation de moyens.

Livraison d'un export conforme à un format défini : peut se rapprocher d'une obligation de résultat.

Disponibilité contractuelle de 99,9 % : engagement objectivable.

Correction d'un incident dans un délai contractuel : engagement mesurable.

Obtention d'un gain métier dépendant de multiples facteurs : beaucoup plus difficile à qualifier comme résultat garanti.

Il faut donc raisonner obligation par obligation.

11. L'inexécution contractuelle : la boîte à outils de l'article 1217

L'article 1217 du Code civil est particulièrement utile pour comprendre ce qui se passe lorsqu'une obligation n'est pas exécutée ou est imparfaitement exécutée.

Il prévoit notamment plusieurs réponses possibles :

• suspendre sa propre obligation ;
• demander l'exécution forcée ;
• obtenir une réduction du prix ;
• provoquer la résolution du contrat ;
• demander réparation des conséquences de l'inexécution.

Certaines sanctions compatibles peuvent être cumulées.

Pour un chef de projet IT, cette disposition permet de comprendre qu'un litige ne se réduit pas à :

« demander des dommages-intérêts ».

Le droit dispose d'une palette de remèdes.

12. Résiliation et résolution : attention au vocabulaire

Ces mots sont souvent employés comme synonymes dans les conversations professionnelles.

Juridiquement, il est préférable de les distinguer.

La résolution sanctionne notamment l'inexécution d'un contrat et peut entraîner sa disparition selon les conditions prévues par le Code civil.

L'article 1224 prévoit que la résolution peut résulter :

• d'une clause résolutoire ;
• d'une notification du créancier en cas d'inexécution suffisamment grave ;
• d'une décision de justice.

La résiliation est traditionnellement utilisée lorsque la disparition du contrat produit principalement ses effets pour l'avenir, ce qui est particulièrement pertinent pour les contrats à exécution successive.

Dans une conversation professionnelle, les deux termes sont parfois mélangés.

Dans une analyse juridique sérieuse, mieux vaut vérifier le mécanisme exact.

13. Le mot clé : « inexécution suffisamment grave »

Toute anomalie informatique ne permet évidemment pas de faire disparaître un contrat.

L'article 1224 parle d'une inexécution suffisamment grave.

Le juge doit donc apprécier la gravité.

Imaginez une application comportant 200 fonctionnalités.

Trois scénarios :

Scénario A : une faute d'orthographe apparaît sur une page secondaire.

Scénario B : une fonctionnalité importante fonctionne mal mais un contournement existe.

Scénario C : les traitements comptables centraux produisent des montants erronés et aucune clôture fiable n'est possible.

Les trois situations constituent potentiellement des non-conformités.

Elles n'ont manifestement pas la même gravité.

Cette idée explique pourquoi la qualification fonctionnelle des anomalies est importante.

14. Recette informatique : là où la technique rencontre la preuve

La recette constitue l'un des objets les plus intéressants juridiquement.

Pour le projet, elle répond à la question :

« Est-ce que ce qui a été développé fonctionne conformément aux attentes ? »

Pour le droit, elle contribue à répondre à une autre question :

« Peut-on démontrer que la prestation livrée était conforme à ce qui était dû ? »

Une recette correctement organisée doit donc permettre de reconstruire :

• les exigences testées ;
• les scénarios ;
• les données utilisées ;
• les résultats attendus ;
• les résultats obtenus ;
• les anomalies ;
• leur criticité ;
• les réserves ;
• leur correction ;
• l'acceptation finale.

Une recette floue crée une zone de risque.

15. La charge de la preuve : qui doit prouver quoi ?

L'article 1353 du Code civil formule un principe central :

celui qui réclame l'exécution d'une obligation doit la prouver ; celui qui prétend être libéré doit justifier le paiement ou le fait ayant entraîné l'extinction de son obligation.

C'est la charge de la preuve.

Cette notion transforme complètement la manière de considérer les artefacts techniques.

Un log peut être une preuve.

Un ticket Jira peut être une preuve.

Un email peut être une preuve.

Un compte rendu de COPIL peut être une preuve.

Une validation de recette peut être une preuve.

Un commit Git peut contribuer à une chronologie.

Un historique de déploiement peut établir une date.

Une alerte de monitoring peut établir la survenance d'un incident.

Une documentation d'architecture peut démontrer ce qui avait été prévu.

Le système d'information ne produit donc pas uniquement des données opérationnelles.

Il produit potentiellement des traces probatoires.

16. Le triptyque faute, préjudice, lien de causalité

Demander réparation suppose généralement de construire un raisonnement autour de trois éléments.

La faute ou l'inexécution

Une obligation n'a pas été respectée.

Le préjudice

Quelqu'un a subi une conséquence dommageable.

Le lien de causalité

Il faut relier suffisamment le dommage à l'inexécution invoquée.

L'article 1231-1 prévoit notamment la condamnation aux dommages-intérêts en raison de l'inexécution ou du retard, sauf notamment lorsque l'exécution a été empêchée par la force majeure.

Ce troisième élément est souvent sous-estimé.

Une entreprise peut subir une perte financière en même temps qu'un incident informatique sans que l'intégralité de cette perte soit juridiquement imputable au prestataire.

La causalité doit être établie.

17. Réversibilité : probablement l'une des notions les plus importantes du cloud

Nous arrivons maintenant au cœur de la Data.

Imaginez que votre entreprise utilise pendant dix ans une solution SaaS.

Le système contient :

• des millions d'enregistrements ;
• des pièces jointes ;
• des historiques ;
• des utilisateurs ;
• des règles ;
• des métadonnées ;
• des référentiels ;
• des relations entre objets.

L'entreprise change de fournisseur.

Le prestataire répond :

« Bien sûr, vos données vous appartiennent. Voici un fichier CSV. »

Techniquement, la question n'est pas résolue.

La vraie question est :

Peut-on reconstruire un système exploitable à partir de ce qui a été restitué ?

C'est là qu'intervient la réversibilité.

18. Réversibilité, restitution et portabilité : trois notions différentes

Ces notions sont proches mais doivent être distinguées.

Restitution

Le prestataire remet au client des données ou éléments qu'il détenait.

Réversibilité

La réversibilité est plus large.

Elle organise la capacité à sortir d'un système ou d'un prestataire et à reprendre le service ailleurs.

Elle peut impliquer :

• données ;
• historique ;
• formats ;
• schémas ;
• documentation ;
• procédures ;
• configurations ;
• interfaces ;
• assistance ;
• calendrier de migration.

Portabilité

Le terme possède notamment une signification spécifique en droit des données personnelles avec l'article 20 du RGPD.

Il ne faut donc pas employer automatiquement « portabilité RGPD » pour parler d'une migration technique B2B.

19. Tribunal judiciaire de Paris : la restitution existe même lorsque le contrat est silencieux

Une décision récente du Tribunal judiciaire de Paris, RG n° 21/08576, mérite une attention particulière.

À la fin d'une relation portant sur un logiciel de gestion intégré, le prestataire informatique n'avait pas transmis les bases de données alimentant les logiciels.

Il conditionnait leur restitution à un paiement supplémentaire.

Problème : le contrat ne décrivait pas précisément cette restitution.

Le prestataire pouvait donc tenter un raisonnement simple :

« Il n'existe aucune clause de réversibilité. Je ne suis pas tenu de réaliser gratuitement cette opération. »

Le tribunal ne suit pas ce raisonnement.

Il considère en substance que la fin d'un contrat informatique portant sur un logiciel de gestion intégré ne se conçoit pas sans transfert des bases de données qui alimentent le logiciel.

Il ajoute qu'en l'absence de clause prévoyant un paiement spécifique, le prestataire ne pouvait pas subordonner cette restitution à un prix supplémentaire.

Cette décision est conceptuellement très importante.

Elle montre les limites du raisonnement :

silence contractuel = absence d'obligation.

20. Mais ne faisons surtout pas de cette jurisprudence une excuse pour rédiger de mauvais contrats

La conclusion opérationnelle ne doit surtout pas être :

« Inutile d'écrire une clause de réversibilité puisque le juge nous protégera. »

Ce serait exactement l'inverse de la bonne pratique.

Une autre décision du Tribunal judiciaire de Paris du 11 février 2025 montre à quoi ressemble une clause beaucoup plus structurée.

Le contrat indiquait notamment que les données du client restaient ses données et organisait leur restitution.

La clause de réversibilité prévoyait un fichier électronique standard, l'historique ainsi que les dessins d'enregistrement afin de permettre la reprise des prestations.

Voilà la différence entre :

« rendez-moi mes données »

et

« rendez-moi un patrimoine informationnel techniquement réutilisable ».

21. Une bonne clause de réversibilité Data devrait penser comme un architecte

Une clause sérieuse devrait au minimum poser les questions suivantes.

Périmètre

Qu'est-ce qui doit être restitué ?

• données métier ;
• données historiques ;
• référentiels ;
• pièces jointes ;
• métadonnées ;
• journaux utiles ;
• configurations ;
• dictionnaires ;
• schémas.

Format

Sous quelle forme ?

Un export propriétaire inutilisable n'a pas la même valeur qu'un format documenté et standard.

Intégrité

Comment vérifier que l'export est complet ?

Documentation

Les structures sont-elles compréhensibles ?

Temporalité

Quand commence la réversibilité ?

Combien de temps dure-t-elle ?

Assistance

Le prestataire doit-il accompagner le repreneur ?

Sécurité

Comment transférer les données ?

Suppression

Quand les copies résiduelles seront-elles supprimées ?

Preuve

Comment démontrer la complétude de l'opération ?

Nous voyons ici quelque chose de remarquable :

Une bonne clause juridique ressemble parfois à une bonne spécification d'architecture.

22. « Propriété des données » : expression pratique mais juridiquement dangereuse

Dans les entreprises, on dit souvent :

« Les données appartiennent au client. »

La formule est utile opérationnellement.

Mais juridiquement, la situation est plus complexe.

La donnée n'est pas nécessairement un bien appropriable exactement comme une voiture ou un ordinateur.

Différents droits peuvent se superposer :

• droit des contrats ;
• droit d'auteur ;
• droit sui generis des bases de données ;
• secret des affaires ;
• protection des données personnelles ;
• obligations de confidentialité ;
• droits sectoriels.

Il vaut donc mieux demander :

Quels droits portent sur ces données, sur leur structure, sur leur utilisation et sur leur extraction ?

plutôt que :

Qui est propriétaire de la donnée ?

23. Le droit sui generis des bases de données

Le Code de la propriété intellectuelle protège notamment le producteur d'une base de données.

L'article L.341-1 définit le producteur comme celui qui prend l'initiative et le risque des investissements correspondants et prévoit une protection lorsque la constitution, la vérification ou la présentation du contenu représente un investissement financier, matériel ou humain substantiel.

Point essentiel :

la protection de la base n'est pas nécessairement la propriété de chaque donnée élémentaire qu'elle contient.

C'est une distinction conceptuelle importante.

Base de données et données ne doivent pas être confondues.

24. Logiciel : encore un autre régime

Le logiciel relève notamment du droit d'auteur avec des dispositions particulières du Code de la propriété intellectuelle.

L'article L.122-6 réserve notamment à l'auteur certains droits concernant :

• la reproduction ;
• l'adaptation ;
• la modification ;
• la mise sur le marché.

Ainsi, dans une même plateforme Data, plusieurs objets juridiques peuvent coexister :

code source

logiciel

base de données

données

documentation

modèle de données

secret d'affaires

données personnelles

La question :

« À qui appartient la plateforme ? »

est donc juridiquement beaucoup trop grossière.

25. RGPD : passer d'un droit documentaire à un droit d'architecture

Le RGPD est parfois réduit à :

• consentement ;
• cookies ;
• mentions d'information ;
• formulaires ;
• registre des traitements.

C'est une vision extrêmement limitée.

Le RGPD contient des exigences qui pénètrent directement l'architecture du système d'information.

26. Le concept central : le traitement

Le RGPD ne raisonne pas d'abord en termes de « fichier ».

Il raisonne en termes de traitement de données à caractère personnel.

Cela permet de penser le cycle de vie :

collecter → stocker → consulter → transformer → croiser → transférer → analyser → archiver → supprimer.

Pour un architecte Data, c'est particulièrement naturel.

Un pipeline constitue une chaîne de traitements.

27. Responsable du traitement et sous-traitant

Voici une distinction qu'il faut savoir expliquer correctement.

Responsable du traitement

Il détermine les finalités et les moyens essentiels du traitement.

Question mentale :

Pourquoi traite-t-on ces données et selon quelle logique essentielle ?

Sous-traitant

Il traite des données pour le compte du responsable du traitement.

La qualification ne dépend pas uniquement du titre inscrit dans un contrat.

Elle dépend du rôle réel joué par les acteurs.

Cette idée est capitale.

On ne devient pas juridiquement sous-traitant simplement parce qu'une clause nous appelle « sous-traitant ».

28. Externaliser le traitement ne signifie pas externaliser la responsabilité

L'article 28 du RGPD impose au responsable du traitement de recourir uniquement à des sous-traitants présentant des garanties suffisantes.

Le contrat doit notamment encadrer :

• l'objet ;
• la durée ;
• la nature ;
• la finalité ;
• les catégories de données ;
• les catégories de personnes ;
• les instructions ;
• la confidentialité ;
• la sécurité ;
• la sous-traitance ultérieure.

La CNIL insiste également sur la nécessité de maîtriser la chaîne de sous-traitance et de vérifier les garanties présentées par les sous-traitants, avec un niveau de contrôle adapté au risque.

Traduction cloud :

AWS, Azure, GCP, SaaS, hébergeur ou intégrateur ne constituent pas des trous noirs de responsabilité.

29. Accountability : « être conforme » ne suffit plus

Le RGPD introduit une idée fondamentale souvent appelée accountability.

L'article 5, paragraphe 2, pose que le responsable du traitement doit être responsable du respect des principes et être en mesure de démontrer ce respect.

Deux dimensions apparaissent :

faire correctement

et

pouvoir démontrer que l'on fait correctement.

C'est extraordinairement proche de la logique d'audit informatique.

Vous pouvez avoir une politique de sécurité excellente.

Si personne ne peut démontrer :

• quand elle a été appliquée ;
• à quels systèmes ;
• avec quels contrôles ;
• avec quelles preuves ;
• avec quelles revues ;

la situation juridique est plus fragile.

30. Accountability et observabilité : deux cousins conceptuels

En Data Engineering, l'observabilité répond à la question :

« Puis-je comprendre l'état réel de mon système ? »

L'accountability juridique pose une question analogue :

« Puis-je démontrer la conformité réelle de mon traitement ? »

Les deux concepts ne sont évidemment pas identiques.

Mais ils partagent une philosophie :

une affirmation non observable est difficile à vérifier.

Voilà pourquoi les logs, politiques, contrôles, rapports d'audit, décisions d'architecture et historiques deviennent si importants.

31. Privacy by design : le droit entre dans le diagramme d'architecture

L'article 25 du RGPD impose la protection des données dès la conception et par défaut.

Il exige notamment des mesures techniques et organisationnelles appropriées dès la détermination des moyens du traitement et pendant le traitement lui-même.

Cela signifie que la conformité ne doit pas arriver après la mise en production comme un contrôle administratif.

Elle doit entrer dans la conception.

Par exemple :

Architecture A

Tous les analystes ont accès à toutes les données brutes.

Architecture B

Les données sont segmentées par domaine, les accès sont attribués selon les rôles et les données sensibles sont pseudonymisées.

Ce n'est pas simplement une différence d'architecture.

Cela peut devenir une différence de conformité.

32. Minimisation : « nous pourrions en avoir besoin » n'est pas une stratégie juridique

L'article 5 du RGPD pose le principe de minimisation.

Les données doivent être adéquates, pertinentes et limitées à ce qui est nécessaire au regard des finalités.

En Data, la tentation naturelle est inverse :

« Collectons tout. Nous trouverons peut-être un usage plus tard. »

Le stockage est bon marché.

La donnée peut avoir de la valeur.

L'IA peut éventuellement l'exploiter.

Mais le RGPD ne raisonne pas en termes de coût de stockage.

Il raisonne en termes de nécessité relativement à une finalité.

33. Finalité : probablement le concept RGPD le plus important pour un Data Architect

Une finalité répond à :

Pourquoi traite-t-on cette donnée ?

Ce n'est pas :

« parce qu'elle est dans Snowflake ».

Ce n'est pas :

« parce que SAP nous l'envoie ».

Ce n'est pas :

« parce que le Data Lake l'ingère ».

La finalité est l'objectif poursuivi.

Cette distinction est essentielle parce que beaucoup d'autres règles dépendent de cette finalité :

• minimisation ;
• durée de conservation ;
• base légale ;
• information ;
• compatibilité des traitements ultérieurs.

34. Conservation : le Data Lake n'est pas un grenier infini

Le RGPD prévoit également une limitation de la conservation.

Les données personnelles identifiantes ne doivent pas être conservées plus longtemps que nécessaire au regard des finalités, sous réserve des régimes spécifiques prévus par le règlement.

Techniquement, cela signifie qu'une politique de rétention doit pouvoir devenir :

• une règle ;
• un traitement ;
• une purge ;
• un archivage ;
• une anonymisation ;
• un contrôle.

Une durée écrite dans une politique PDF mais jamais implémentée dans le SI constitue une conformité largement théorique.

35. Affaire Free 2026 : quand la rétention et la cybersécurité se rencontrent

La sanction prononcée contre Free et Free Mobile constitue un cas d'école.

En octobre 2024, un attaquant parvient à pénétrer le système d'information.

Il accède à des données personnelles concernant environ 24 millions de contrats, comprenant notamment des IBAN pour certaines personnes.

En janvier 2026, la CNIL prononce :

• 27 millions d'euros contre Free Mobile ;
• 15 millions contre Free ;

soit 42 millions d'euros au total.

La CNIL relève notamment des insuffisances de sécurité, dont une procédure d'authentification VPN insuffisamment robuste.

Elle relève également des problématiques de conservation excessive de certaines données.

Cette affaire montre une chose fondamentale :

Data Governance et Cybersecurity ne sont pas deux disciplines indépendantes.

Si vous conservez inutilement dix millions de données supplémentaires, vous augmentez potentiellement l'impact d'une compromission.

La minimisation et la rétention sont donc aussi des mécanismes de réduction de la surface d'impact.

36. Article 32 RGPD : la sécurité comme obligation fondée sur le risque

L'article 32 ne fournit pas une checklist universelle.

Il impose des mesures techniques et organisationnelles appropriées au regard notamment :

• de l'état des connaissances ;
• des coûts ;
• de la nature du traitement ;
• de son contexte ;
• de ses finalités ;
• de la probabilité et de la gravité des risques.

Parmi les mesures citées figurent notamment :

• pseudonymisation ;
• chiffrement ;
• confidentialité ;
• intégrité ;
• disponibilité ;
• résilience ;
• capacité de restauration ;
• tests réguliers des mesures de sécurité.

Le mot important est :

appropriées.

Le droit introduit donc une logique de proportionnalité et de risque.

37. Risque juridique et risque technique parlent ici presque la même langue

Un RSSI raisonne :

menace × vulnérabilité × impact.

Le RGPD demande également d'évaluer les risques pour les droits et libertés des personnes.

Les objets ne sont pas parfaitement identiques, mais le rapprochement est puissant.

Une architecture de sécurité peut donc devenir une matérialisation du raisonnement juridique.

38. NEXPUBLICA : l'autorisation défaillante devient un problème juridique

Le cas NEXPUBLICA France est particulièrement instructif.

La société développait un logiciel de gestion de la relation avec les usagers utilisé notamment dans le domaine social.

Des utilisateurs ont découvert qu'ils pouvaient accéder à des documents concernant d'autres personnes.

La CNIL a finalement prononcé en décembre 2025 une sanction de 1,7 million d'euros pour insuffisance des mesures de sécurité.

Pour un développeur, le problème peut être décrit comme :

contrôle d'autorisation défaillant.

Pour un pentester :

potentielle vulnérabilité de contrôle d'accès.

Pour un architecte :

mauvaise isolation des ressources.

Pour la protection des données :

accès non autorisé à des données personnelles.

Même réalité.

Quatre vocabulaires.

39. Authentification et autorisation : distinction indispensable

Une architecture sécurisée doit distinguer :

Authentification

Qui êtes-vous ?

Autorisation

À quoi avez-vous le droit d'accéder ?

Un utilisateur parfaitement authentifié peut réaliser un accès illégitime si le contrôle d'autorisation est défaillant.

Cette distinction technique devient juridiquement essentielle dans les affaires d'accès non autorisé.

40. Le RGPD n'impose pas une technologie précise

Autre idée importante.

Le RGPD ne dit généralement pas :

« utilisez tel produit ».

Il formule des objectifs et obligations.

Cette neutralité technologique est essentielle parce que les technologies évoluent plus vite que les textes.

La question devient :

Les mesures étaient-elles appropriées au risque compte tenu de l'état des connaissances ?

C'est une norme dynamique.

Ce qui pouvait être acceptable il y a dix ans peut ne plus l'être aujourd'hui.

41. Sous-traitance : la chaîne de responsabilité

Imaginez :

Entreprise A utilise SaaS B.

B utilise Cloud C.

C utilise un autre prestataire D pour une partie du service.

Nous obtenons :

A → B → C → D.

Techniquement, c'est une supply chain.

Juridiquement, c'est également une chaîne de responsabilités.

L'article 28 encadre notamment la sous-traitance ultérieure et prévoit que les obligations appropriées soient répercutées dans cette chaîne.

Voilà pourquoi la question :

« Où sont réellement mes données ? »

reste juridiquement pertinente même dans une architecture très abstraite.

42. Schrems II : quand l'architecture cloud rencontre la géopolitique juridique

L'arrêt Schrems II, CJUE, 16 juillet 2020, C-311/18, constitue une décision majeure.

Le contentieux concernait les transferts de données personnelles vers les États-Unis.

La Cour a invalidé le Privacy Shield tout en maintenant, sous conditions, le mécanisme des clauses contractuelles types.

L'idée essentielle est qu'un contrat entre deux entreprises ne peut pas, à lui seul, neutraliser toutes les conséquences du droit applicable dans le pays de destination.

Il faut examiner le niveau réel de protection offert aux données.

Pour l'architecte cloud, la conséquence intellectuelle est majeure :

La localisation logique d'une ressource n'épuise pas la question juridique de l'accès aux données.

Il faut considérer :

• région d'hébergement ;
• entité contractante ;
• sous-traitants ;
• accès support ;
• transferts ;
• clés ;
• législation applicable ;
• garanties supplémentaires.

43. IA : avoir légalement la donnée ne signifie pas pouvoir lui appliquer n'importe quel traitement

Nous arrivons à l'une des décisions françaises les plus intéressantes de 2026.

Le Conseil d'État statue le 30 janvier 2026 sur un dispositif envisagé par la commune de Nice.

Des caméras de vidéoprotection existent.

La ville souhaite utiliser un algorithme pour détecter automatiquement et en continu certains véhicules stationnant irrégulièrement devant les écoles et alerter la police municipale.

La question est subtile.

La vidéoprotection elle-même possède un fondement juridique.

Mais cela suffit-il pour ajouter une couche algorithmique ?

Le Conseil d'État répond négativement.

Il considère que les dispositions autorisant les systèmes de vidéoprotection sur la voie publique ne peuvent, dans leur silence, être interprétées comme autorisant une analyse algorithmique systématique et automatisée des images. Aucune autre disposition applicable ne fournissait cette autorisation.

Voilà un principe mental extrêmement puissant :

Autorisation de collecter ≠ autorisation de traiter de n'importe quelle manière.

44. Pourquoi l'affaire Nice est fondamentale pour la Data et l'IA

Imaginez une entreprise possédant légalement un immense Data Lake.

Un responsable décide :

« Puisque les données sont déjà chez nous, entraînons un modèle dessus. »

Juridiquement, ce raisonnement est incomplet.

Il faut revenir aux questions :

• quelle finalité initiale ?
• quelle base juridique ?
• quel traitement nouveau ?
• quelles personnes concernées ?
• quelle compatibilité ?
• quelles informations ?
• quels risques ?
• quelles règles sectorielles ?
• quel régime AI Act éventuel ?

Le stockage légitime ne crée pas un droit universel d'exploitation.

45. AI Act et RGPD : deux couches différentes

Autre distinction à maîtriser.

Le RGPD réglemente principalement les traitements de données personnelles.

L'AI Act réglemente les systèmes d'intelligence artificielle selon une logique largement fondée sur les risques et les usages.

Un système peut donc être :

• concerné par le RGPD ;
• concerné par l'AI Act ;
• concerné par les deux ;
• éventuellement hors du champ de l'un mais pas nécessairement de l'autre.

Dans l'affaire Nice, le Conseil d'État précise d'ailleurs que son raisonnement subsiste même si le traitement envisagé n'était pas qualifiable de système d'IA à haut risque au sens de l'article 6 du règlement européen sur l'IA.

C'est juridiquement très instructif.

Échapper à une qualification dans un texte ne signifie pas échapper à toutes les autres règles applicables.

46. Le droit fonctionne par superposition de couches

C'est probablement l'un des meilleurs modèles mentaux pour un architecte.

Imaginez une stack juridique.

Couche 1

Droit général des contrats.

Couche 2

Droit de la propriété intellectuelle.

Couche 3

Protection des données personnelles.

Couche 4

Cybersécurité.

Couche 5

Réglementation sectorielle.

Couche 6

AI Act si applicable.

Couche 7

Contrat particulier.

Un même système peut devoir satisfaire plusieurs couches simultanément.

C'est très proche d'une architecture technique.

Un composant peut être conforme au protocole réseau et pourtant violer une règle d'autorisation applicative.

De même, un traitement peut respecter le RGPD et rester interdit par une autre législation.

47. EXTIA 2026 : le droit à l'effacement comme problème d'architecture Data

En juillet 2026, la CNIL sanctionne EXTIA à hauteur de 300 000 euros.

L'affaire fait notamment suite à des plaintes d'anciens salariés et candidats rencontrant des difficultés pour exercer leur droit à l'effacement.

Cette affaire permet de poser une question rarement anticipée lors de la construction des systèmes :

Votre architecture sait-elle réellement oublier quelqu'un ?

Imaginez les données d'un candidat présentes dans :

• ATS ;
• CRM ;
• Data Lake ;
• fichiers Excel ;
• outil emailing ;
• sauvegardes ;
• exports ;
• Data Warehouse ;
• outil d'analytics.

Un bouton :

DELETE FROM candidate

dans une base ne suffit pas nécessairement.

Le droit à l'effacement devient donc un problème de :

data lineage + propagation + rétention + orchestration + gouvernance.

48. Le lineage devient juridiquement intéressant

Le data lineage répond à :

« D'où vient cette donnée et où va-t-elle ? »

Le droit peut poser :

« Où cette donnée personnelle a-t-elle été copiée ? »

Ces deux questions sont presque identiques.

Une organisation incapable de cartographier ses flux rencontrera mécaniquement plus de difficultés lorsqu'elle devra :

• répondre à un droit d'accès ;
• rectifier une information ;
• effacer une personne ;
• analyser une violation ;
• démontrer une conformité.

La gouvernance Data n'est donc pas uniquement une discipline de qualité.

Elle devient une infrastructure de conformité.

49. Le Data Contract prend lui aussi une dimension juridique

Dans l'ingénierie Data moderne, un Data Contract peut définir :

• schéma ;
• types ;
• règles de qualité ;
• fraîcheur ;
• SLA ;
• compatibilité ;
• propriétaires ;
• consommateurs.

Attention toutefois au vocabulaire.

Un Data Contract technique n'est pas nécessairement un contrat juridique.

Le mot « contract » est ici souvent utilisé par analogie.

Mais l'idée est intéressante.

Le Data Contract formalise des attentes entre producteurs et consommateurs.

Le contrat juridique formalise des obligations entre parties.

Les deux peuvent se rencontrer.

Par exemple :

Data Contract technique

customer_id NOT NULL

engagement contractuel

« Le fournisseur garantit un taux de complétude supérieur à 99,5 %. »

Nous passons alors d'une règle technique à une obligation mesurable.

50. SLA, SLO et obligation juridique

Même distinction.

Un SLO est un objectif opérationnel.

Un SLA peut devenir un engagement contractuel assorti de conséquences.

Exemple :

disponibilité cible 99,9 %.

Mais il faut définir :

• période de mesure ;
• exclusions ;
• maintenance ;
• méthode de calcul ;
• source de mesure ;
• fuseau horaire ;
• incident majeur ;
• force majeure ;
• pénalités.

Sinon, le chiffre est moins précis qu'il n'en a l'air.

51. Pourquoi les définitions sont cruciales en droit

Les ingénieurs aiment les types.

INTEGER

STRING

DATE

Le droit aime également les qualifications.

Une grande partie du raisonnement juridique consiste à répondre :

Dans quelle catégorie juridique ce fait entre-t-il ?

C'est ce qu'on appelle la qualification juridique.

Exemple :

fait :

Une entreprise héberge des données pour son client et les traite uniquement selon ses instructions.

qualification possible :

sous-traitant au sens du RGPD.

Autre fait :

deux organisations déterminent ensemble les finalités essentielles.

qualification possible :

responsables conjoints.

La qualification déclenche ensuite un régime juridique.

C'est exactement comme un système de types :

faits → qualification → règles applicables.

52. Qualification juridique et abstraction informatique

Pour un architecte, cette manière de penser est étonnamment familière.

En informatique :

instance → type → comportement.

En droit :

faits → qualification → régime juridique.

Exemple :

John est une instance de Customer.

Une opération particulière est qualifiée juridiquement de traitement de données personnelles.

Une entreprise est qualifiée de responsable du traitement.

Cette qualification entraîne des obligations.

Le juriste et l'architecte utilisent donc tous deux l'abstraction pour rendre le réel manipulable.

53. Jurisprudence : pourquoi deux affaires proches peuvent produire des résultats différents

Parce que le droit dépend fortement des faits.

Dans deux projets ERP apparemment similaires, plusieurs différences peuvent modifier l'analyse :

• contrat différent ;
• client plus ou moins averti ;
• alertes envoyées ;
• réserves documentées ;
• recette différente ;
• modifications demandées en cours de projet ;
• collaboration insuffisante du client ;
• dépassement accepté ;
• obligations différentes.

Il faut donc éviter :

« Un tribunal a décidé X, donc X est toujours vrai. »

La bonne formulation est :

Dans telle configuration factuelle et juridique, la juridiction a retenu telle solution.

54. Ratio decidendi : identifier ce qui fait réellement la décision

Lorsqu'on lit une décision, tout n'a pas la même importance.

Il faut identifier le raisonnement nécessaire à la solution.

Dans une lecture professionnelle, demandons :

1. Quels sont les faits déterminants ?
2. Quelle question juridique est posée ?
3. Quelle règle est appliquée ?
4. Comment les faits sont-ils qualifiés ?
5. Quelle conclusion en résulte ?

Cette méthode évite de transformer une phrase isolée en principe universel.

55. Jurisprudence constante, arrêt de principe et décision d'espèce

Trois expressions utiles.

Décision d'espèce

La solution est fortement liée aux circonstances particulières.

Arrêt de principe

La juridiction formule une règle ou interprétation ayant une portée plus générale.

Jurisprudence constante

Plusieurs décisions convergent durablement vers une même solution.

Dire :

« La jurisprudence considère... »

est donc plus fort que :

« Dans une décision, le tribunal a considéré... »

Le vocabulaire doit refléter le niveau réel de généralité.

56. Tribunal, cour d'appel, Cour de cassation : ne pas confondre les niveaux

Autre compétence indispensable.

Tribunal

Juge généralement l'affaire en première instance.

Cour d'appel

Réexamine l'affaire après appel, dans les limites du recours.

Cour de cassation

Elle n'est pas un troisième procès complet des faits.

Elle contrôle principalement la correcte application du droit par les juridictions du fond.

C'est pourquoi un arrêt de Cour de cassation possède une importance particulière pour comprendre l'interprétation du droit privé.

57. Conseil d'État

Dans l'ordre administratif, le Conseil d'État occupe notamment la fonction de juridiction suprême.

C'est pourquoi sa décision du 30 janvier 2026 sur la vidéoprotection algorithmique possède une portée particulièrement intéressante.

58. CJUE : pourquoi une affaire non française peut devenir essentielle en France

La Cour de justice de l'Union européenne interprète le droit de l'Union.

Lorsqu'elle interprète le RGPD, cette interprétation intéresse directement la France.

C'est pourquoi des affaires comme Schrems II sont incontournables dans une bibliothèque française de jurisprudence Data.

Nationalité du litige et portée juridique ne doivent donc pas être confondues.

59. CNIL : jurisprudence ou doctrine ?

Il faut être précis.

La CNIL est une autorité administrative indépendante.

Elle n'est pas une juridiction judiciaire.

Sa formation restreinte peut néanmoins prononcer des sanctions.

Ses décisions peuvent ensuite faire l'objet de recours devant le Conseil d'État.

Dans un discours rigoureux, mieux vaut donc parler selon le cas de :

• décision de la CNIL ;
• délibération ;
• sanction ;
• doctrine de la CNIL ;
• recommandation ;

et réserver le terme « jurisprudence » principalement aux décisions juridictionnelles.

Les Tables Informatique et Libertés 2026 de la CNIL sont justement précieuses parce qu'elles organisent ensemble jurisprudence européenne et nationale, pratique décisionnelle de la CNIL et positions doctrinales pertinentes.

60. Contrat, loi et jurisprudence : le modèle mental à retenir

Nous pouvons maintenant construire une architecture mentale.

Niveau 1 : la norme

Que dit le texte ?

Exemple :

article 32 RGPD.

Niveau 2 : le contrat

Qu'ont précisément prévu les parties ?

Exemple :

MFA obligatoire, RTO quatre heures, sauvegarde quotidienne.

Niveau 3 : les faits

Que s'est-il réellement passé ?

Niveau 4 : la preuve

Comment le démontrer ?

Niveau 5 : la qualification

Comment le droit décrit-il ces faits ?

Niveau 6 : l'application

Quelle règle s'applique ?

Niveau 7 : la conséquence

Exécution, responsabilité, réparation, résolution, sanction, etc.

C'est cette chaîne qu'il faut apprendre à reconstruire.

61. Le contrat IT comme architecture de responsabilité

Un contrat informatique mature ne devrait pas seulement dire :

« Le prestataire développe une application. »

Il devrait répartir les responsabilités.

Qui :

• exprime le besoin ?
• valide les spécifications ?
• fournit les données ?
• contrôle leur qualité ?
• configure les accès ?
• réalise les sauvegardes ?
• teste la restauration ?
• surveille la plateforme ?
• corrige les incidents ?
• décide des durées de conservation ?
• gère les droits RGPD ?
• pilote les sous-traitants ?
• assure la réversibilité ?

Cette matrice peut être plus importante que vingt pages de formulations générales.

62. Architecture Decision Records : une utilité juridique indirecte

Les ADR documentent généralement :

• contexte ;
• options ;
• décision ;
• justification ;
• conséquences.

Exemple :

Pourquoi avons-nous choisi une architecture multi-région ?

Ou :

Pourquoi conservons-nous les logs pendant douze mois ?

Dans un contentieux, ce type de documentation peut aider à reconstruire le raisonnement qui existait au moment de la décision.

Cela ne transforme pas automatiquement l'ADR en preuve absolue.

Mais il contribue à l'histoire documentaire du projet.

63. « Je ne savais pas » est rarement une stratégie de gouvernance

L'un des enseignements transversaux des décisions IT est la valorisation de la diligence.

Un professionnel est justement choisi pour son expertise.

Plus son expertise est élevée, plus il peut être attendu qu'il :

• identifie certaines difficultés ;
• alerte ;
• conseille ;
• documente.

L'expertise produit donc de la valeur.

Mais elle produit également des responsabilités.

64. Le devoir de collaboration du client

Il serait néanmoins faux de présenter systématiquement le prestataire comme seul responsable.

Un projet informatique est généralement coconstruit.

Le client doit lui aussi collaborer.

Il peut notamment devoir :

• exprimer ses besoins ;
• fournir les informations nécessaires ;
• rendre disponibles les interlocuteurs ;
• valider ;
• tester ;
• signaler les anomalies ;
• respecter certaines dépendances ;
• fournir les environnements ou accès prévus.

La responsabilité peut donc être partagée selon les faits.

Le devoir de conseil du prestataire ne transforme pas le client en acteur passif.

65. La meilleure protection juridique commence souvent avant le contrat

Un projet bien cadré réduit simultanément :

• risque technique ;
• risque financier ;
• risque organisationnel ;
• risque juridique.

Avant signature, il faut donc documenter :

objectifs

hypothèses

volumétrie

dépendances

interfaces

responsabilités

contraintes

risques

critères d'acceptation

exit strategy

Le juridique n'arrive pas après l'architecture.

Il commence avec elle.

66. Cybersecurity : conformité ne signifie pas absence d'incident

Une autre erreur fréquente serait :

« Il y a eu une cyberattaque, donc l'entreprise était nécessairement en faute. »

Ce raisonnement est trop simple.

Aucun système réaliste ne garantit un risque zéro.

La question juridique est souvent plutôt :

Les mesures prises étaient-elles appropriées compte tenu du risque ?

C'est précisément la logique de l'article 32.

Une entreprise peut subir une attaque sophistiquée malgré des mesures sérieuses.

Inversement, le simple fait d'avoir acheté un firewall ou un EDR ne démontre pas une sécurité appropriée.

67. Mesures techniques et mesures organisationnelles

Le RGPD emploie constamment cette paire.

Technique

• MFA ;
• chiffrement ;
• segmentation ;
• sauvegarde ;
• pseudonymisation ;
• journalisation ;
• contrôle d'accès.

Organisationnel

• procédures ;
• responsabilités ;
• formation ;
• revue des accès ;
• gouvernance ;
• processus d'incident ;
• audits.

Une technologie sans processus peut être inefficace.

Un processus sans technologie peut être fictif.

La conformité exige souvent les deux.

68. Résilience : un concept désormais explicitement juridique

L'article 32 cite la capacité à assurer notamment la disponibilité et la résilience constantes des systèmes et services de traitement.

Pour un architecte, ce mot est familier.

Redondance.

Retry.

Failover.

Backup.

Disaster recovery.

Graceful degradation.

Mais il possède ici une portée normative.

La résilience n'est donc plus uniquement une qualité d'ingénierie.

Dans certains contextes, elle participe directement à la conformité.

69. Restauration : le backup n'est pas l'objectif

L'article 32 évoque également la capacité à rétablir la disponibilité des données et leur accès dans des délais appropriés après un incident.

C'est exactement la distinction classique :

avoir une sauvegarde

versus

être capable de restaurer.

Un backup jamais testé est une promesse.

Une restauration testée est une capacité démontrée.

Encore une fois :

accountability.

70. La jurisprudence IT enseigne finalement une culture de la preuve

Lorsque tout fonctionne, beaucoup d'informations restent implicites.

Quand le contentieux arrive, l'implicite devient problématique.

Qui avait demandé cette modification ?

Quand ?

Pourquoi ?

Qui avait validé ?

Le risque avait-il été signalé ?

Le client l'avait-il accepté ?

La version avait-elle été testée ?

Quelle configuration était en production ?

Quelles données avaient été supprimées ?

La sauvegarde avait-elle été testée ?

Le prestataire avait-il remis l'export ?

Toutes ces questions possèdent une réponse technique.

Mais le tribunal demandera surtout :

Pouvez-vous l'établir ?

71. De l'observabilité technique à l'observabilité contractuelle

On peut donc proposer un concept utile :

Observabilité contractuelle

Capacité à reconstruire, à partir des traces du projet :

• ce qui était dû ;
• ce qui a été décidé ;
• ce qui a été livré ;
• ce qui a été accepté ;
• ce qui a échoué ;
• qui en avait la responsabilité.

Une organisation mature devrait pouvoir observer son contrat comme elle observe sa production.

72. Les huit réflexes juridiques du professionnel IT/Data

Face à n'importe quel problème, posons huit questions.

1. Quel est l'objet ?

Logiciel ? Donnée ? Base ? Service ? Algorithme ?

2. Quelle est la relation ?

Client ? Prestataire ? Sous-traitant ? Éditeur ?

3. Quelle obligation ?

Livrer ? Conseiller ? Sécuriser ? Informer ? Restituer ?

4. Quelle source ?

Contrat ? Code civil ? RGPD ? Réglementation sectorielle ?

5. Quels faits ?

Que s'est-il réellement passé ?

6. Quelle preuve ?

Logs ? Emails ? recette ? audit ?

7. Quel préjudice ?

Financier ? opérationnel ? atteinte aux droits ?

8. Quelle conséquence ?

Correction ? indemnisation ? résolution ? sanction ?

Ce modèle suffit déjà à améliorer considérablement la qualité d'une discussion sur un incident IT.

73. Petit lexique pour parler correctement

Obligation

Comportement juridiquement exigible d'une personne envers une autre.

Débiteur de l'obligation

Celui qui doit exécuter.

Attention : « débiteur » ne signifie pas uniquement « celui qui doit de l'argent ».

Créancier de l'obligation

Celui qui peut exiger l'exécution.

Inexécution

Absence d'exécution ou exécution imparfaite d'une obligation.

Responsabilité contractuelle

Responsabilité résultant d'un manquement à une obligation contractuelle.

Préjudice

Dommage juridiquement pris en considération.

Causalité

Lien entre le fait générateur et le dommage invoqué.

Charge de la preuve

Détermination de celui qui doit établir un fait.

Bonne foi

Exigence gouvernant notamment négociation, formation et exécution du contrat.

Devoir d'information

Obligation de communiquer certaines informations pertinentes.

Devoir de conseil

Obligation plus active pouvant conduire le professionnel à comprendre le besoin, alerter et orienter.

Obligation de moyens

Engagement de déployer les diligences requises sans garantir systématiquement le résultat.

Obligation de résultat

Engagement portant sur l'obtention d'un résultat déterminé.

Résolution

Mécanisme mettant fin au contrat notamment en raison d'une inexécution suffisamment grave selon les conditions légales.

Réversibilité

Organisation de la sortie d'un service permettant sa reprise chez le client ou un autre prestataire.

Responsable du traitement

Acteur déterminant les finalités et les moyens essentiels d'un traitement de données personnelles.

Sous-traitant

Acteur traitant les données pour le compte du responsable.

Finalité

Objectif poursuivi par le traitement.

Minimisation

Limitation des données à celles nécessaires aux finalités.

Accountability

Responsabilité accompagnée de la capacité à démontrer la conformité.

Privacy by design

Intégration de la protection des données dès la conception.

74. Ce que la jurisprudence change dans la pratique d'un architecte

Un architecte pourrait penser :

« Mon travail consiste à définir la meilleure solution technique. »

Les affaires étudiées suggèrent une définition plus complète.

L'architecte doit également rendre explicites :

• hypothèses ;
• contraintes ;
• risques ;
• dépendances ;
• responsabilités ;
• impacts ;
• décisions.

Parce qu'une architecture est aussi une distribution de conséquences.

75. Ce que la jurisprudence change dans la pratique d'un consultant

Le consultant doit comprendre que son conseil peut devenir un objet juridique.

Il ne suffit donc pas de produire :

« Option A recommandée. »

Il est préférable de documenter :

contexte

hypothèses

options

risques

limites

recommandation

conditions de réussite

décision du client

Le conseil devient alors traçable.

76. Ce que la jurisprudence change dans la Data Governance

La gouvernance Data ne devrait plus être présentée uniquement comme :

catalogue + ownership + qualité.

Elle devrait également inclure :

• finalités ;
• droits d'accès ;
• rétention ;
• lineage ;
• classifications ;
• obligations réglementaires ;
• règles d'effacement ;
• localisation ;
• sous-traitance ;
• traçabilité.

La gouvernance devient le point de rencontre entre architecture, métier et droit.

77. Ce que la jurisprudence change dans le cloud

Avant de choisir un service cloud, les questions techniques classiques sont :

• performance ;
• disponibilité ;
• coût ;
• scalabilité.

Il faut ajouter :

• localisation ;
• transfert ;
• sous-traitants ;
• réversibilité ;
• formats de sortie ;
• chiffrement ;
• contrôle des clés ;
• logs ;
• suppression ;
• auditabilité ;
• droit applicable.

Le TCO d'un cloud devrait donc intégrer le coût de sortie.

78. Ce que la jurisprudence change dans l'IA

Avant :

« Avons-nous suffisamment de données pour entraîner le modèle ? »

Après lecture juridique :

« Avons-nous le droit d'utiliser ces données pour cette finalité et ce traitement ? »

Avant :

« Le modèle fonctionne-t-il ? »

Après :

« Comment sa décision affecte-t-elle les personnes ? »

Avant :

« Le système est-il high-risk au sens de l'AI Act ? »

Après :

« Quelles autres normes continuent de s'appliquer même s'il ne l'est pas ? »

C'est exactement la leçon de l'affaire Nice.

79. Dix clauses que je regarderais immédiatement dans un contrat Data/IT

Pour terminer la partie opérationnelle, voici dix familles contractuelles particulièrement importantes.

1. Objet et périmètre

Que doit réellement fournir le prestataire ?

2. Spécifications et expression de besoin

Quels documents font foi ?

3. Gouvernance des changements

Comment gère-t-on les évolutions ?

4. Recette

Comment constate-t-on la conformité ?

5. SLA

Comment mesure-t-on le service ?

6. Sécurité

Quelles obligations techniques et organisationnelles ?

7. Données

Quels usages, responsabilités et restrictions ?

8. Réversibilité

Comment sort-on ?

9. Responsabilité

Quels préjudices et plafonds ?

10. Preuve et audit

Comment vérifier les obligations ?

Un onzième élément mérite souvent une place autonome :

11. Sous-traitance

Qui peut intervenir derrière le prestataire principal ?

80. La leçon la plus importante : une bonne architecture et un bon contrat racontent la même histoire

Prenons un exemple final.

Le contrat dit :

seules les personnes autorisées accèdent aux données sensibles.

L'architecture devrait montrer :

RBAC + IAM + segmentation + revue des accès.

Le contrat dit :

les données sont supprimées après cinq ans.

L'architecture devrait montrer :

retention policy + purge + contrôle.

Le contrat dit :

restauration en moins de quatre heures.

L'architecture devrait montrer :

backup + réplication + procédure + tests de restauration.

Le contrat dit :

réversibilité complète.

L'architecture devrait montrer :

export + format + métadonnées + documentation + procédure.

Quand contrat et architecture racontent deux histoires différentes, le risque augmente.

Conclusion : le droit comme architecture des responsabilités

L'étude de la jurisprudence IT et Data révèle finalement quelque chose de beaucoup plus profond qu'une collection de procès informatiques.

Le droit et l'ingénierie cherchent tous deux à organiser la complexité.

L'ingénieur demande :

Comment le système doit-il fonctionner ?

Le juriste demande :

Qui doit quoi à qui, selon quelle règle, et que se passe-t-il lorsque cette règle n'est pas respectée ?

L'architecte définit :

composants → interfaces → dépendances → responsabilités techniques.

Le contrat définit :

parties → obligations → conditions → responsabilités juridiques.

Le parallèle est puissant.

Dans les deux cas, les zones mal définies deviennent des zones de risque.

Les décisions françaises récentes le montrent particulièrement bien.

Le devoir de conseil oblige le professionnel informatique à dépasser une posture de simple exécutant lorsque son expertise est précisément la raison pour laquelle il intervient. La présence de compétences informatiques chez le client ne suffit pas nécessairement à neutraliser ce devoir.

La réversibilité montre qu'une donnée enfermée dans un système n'est pas réellement maîtrisée. Le Tribunal judiciaire de Paris a pu considérer que la fin d'un contrat portant sur un logiciel de gestion ne se concevait pas sans transfert des bases qui l'alimentaient, même lorsque le contrat n'avait pas correctement organisé cette sortie.

Le RGPD montre que la protection des données n'est pas une couche documentaire ajoutée après le développement. Privacy by design, minimisation, sécurité, rétention, accountability et contrôle des sous-traitants touchent directement l'architecture.

Les sanctions Free et NEXPUBLICA montrent que des choix très concrets d'authentification, de contrôle d'accès ou de conservation peuvent acquérir une qualification juridique et produire des conséquences financières considérables.

Enfin, l'affaire Nice rappelle une règle qui deviendra probablement de plus en plus importante avec l'intelligence artificielle :

Disposer légalement d'une donnée ou d'un flux ne signifie pas disposer d'une autorisation générale pour lui appliquer n'importe quel traitement algorithmique.

Le Conseil d'État a précisément refusé de déduire de l'autorisation légale de vidéoprotection une autorisation implicite d'analyse algorithmique systématique et automatisée.

Pour un professionnel IT ou Data, apprendre le droit ne consiste donc pas à mémoriser des numéros d'articles.

Il faut apprendre à penser selon une chaîne :

faits → qualification → obligation → preuve → inexécution → préjudice → causalité → conséquence.

Puis selon une seconde chaîne, plus proche de l'architecture :

finalité → données → traitement → acteur → responsabilité → contrôle → preuve.

À partir du moment où ces deux modèles mentaux sont acquis, le vocabulaire juridique cesse d'être étranger.

Une expression de besoin devient aussi la description d'une obligation potentielle.

Une recette devient aussi un mécanisme de preuve.

Un SLA devient aussi un engagement mesurable.

Un ADR devient aussi une trace de décision.

Un IAM devient aussi une matérialisation du principe de contrôle des accès.

Un data lineage devient aussi une capacité à exercer certains droits et à investiguer un incident.

Une politique de rétention devient aussi l'implémentation d'une obligation de conservation limitée.

Un plan de réversibilité devient aussi la garantie que la dépendance technique ne se transformera pas en captivité opérationnelle.

Et une architecture devient finalement ce qu'elle a toujours été sans que nous utilisions nécessairement ces mots :

une distribution explicite des responsabilités.

Sources juridiques principales

Code civil

Article 1103, force obligatoire des contrats.

Article 1104, bonne foi dans la négociation, la formation et l'exécution.

Article 1112-1, devoir précontractuel d'information et mécanisme de preuve.

Article 1217, sanctions de l'inexécution contractuelle.

Article 1224, résolution pour inexécution suffisamment grave.

Article 1231-1, dommages-intérêts résultant de l'inexécution ou du retard.

Article 1353, charge de la preuve.

Propriété intellectuelle

Code de la propriété intellectuelle, article L.122-6, droits d'exploitation relatifs au logiciel.

Code de la propriété intellectuelle, article L.341-1, protection du producteur de base de données.

Jurisprudence informatique française

Cour de cassation, chambre commerciale, 6 mai 2003, pourvoi n° 00-11.530, devoir de conseil du prestataire informatique et compétences internes du client.

Tribunal judiciaire de Paris, RG n° 21/08576, restitution des bases de données et absence de clause de réversibilité.

Tribunal judiciaire de Paris, 11 février 2025, RG n° 20/08670, clauses de restitution et de réversibilité prévoyant notamment données, historique et dessins d'enregistrement.

Tribunal de commerce de Chartres, RG n° 2025J00136, devoir de cadrage et de conseil et dérive budgétaire d'un projet informatique.

Protection des données

Règlement (UE) 2016/679, notamment principes de finalité, minimisation, conservation et accountability.

RGPD, article 25, protection des données dès la conception et par défaut.

RGPD, article 28, encadrement de la sous-traitance.

RGPD, article 32, sécurité du traitement, confidentialité, intégrité, disponibilité, résilience et restauration.

CNIL, Tables Informatique et Libertés, édition 2026, corpus de référence regroupant jurisprudence et pratique décisionnelle relatives à la protection des données.

CNIL, sanctions Free Mobile et Free, janvier 2026, 27 et 15 millions d'euros.

CNIL, NEXPUBLICA France, décembre 2025, sanction de 1,7 million d'euros pour insuffisance des mesures de sécurité.

CNIL, EXTIA, juillet 2026, sanction de 300 000 euros notamment concernant le droit à l'effacement.

Transferts internationaux

CJUE, grande chambre, 16 juillet 2020, Data Protection Commissioner v Facebook Ireland Ltd et Maximillian Schrems, C-311/18, dit « Schrems II ».

Algorithmes et intelligence artificielle

Conseil d'État, 30 janvier 2026, Commune de Nice, n° 506370, analyse algorithmique systématique et automatisée d'images issues de la vidéoprotection.

Cet article constitue une analyse pédagogique de notions et décisions juridiques appliquées aux systèmes d'information et à la Data. Il ne remplace pas l'analyse d'un avocat sur une situation contractuelle ou contentieuse particulière.