# Kulular Teknoloji, corpus en français

## Le déroulement d’un projet logiciel, du devis à la livraison

Source : https://kulular.com.tr/fr/publications/deroulement-d-un-projet-logiciel

L’une des premières questions d’une organisation qui veut faire développer un logiciel porte sur le déroulement. Quand verra-t-elle quoi, qu’attendra-t-on d’elle, à quel moment le travail sera-t-il considéré comme terminé.
Dans cet article, je décris les étapes par lesquelles passe un projet, du premier rendez-vous à la maintenance. Les étapes n’ont pas la même durée dans chaque projet. Pour un petit projet, plusieurs tiennent en une seule réunion. Mais aucune n’est sautée, car une étape sautée revient sous forme de surprise à la fin du projet.
Le premier rendez-vous
Au premier rendez-vous, nous ne parlons pas de prix. Nous cherchons à comprendre ce que l’on veut faire, comment le travail se fait aujourd’hui et ce qui doit changer. Qui va l’utiliser, quelles données seront traitées, avec quels systèmes il faudra échanger.
À la fin de ce rendez-vous, il nous arrive de dire qu’un logiciel sur mesure n’est pas nécessaire. Si un produit existant fait l’affaire, le dire dès le départ fait gagner du temps à tout le monde.
Le cadrage
Si le besoin n’est pas clair, nous proposons une courte phase de cadrage. Quelques ateliers, un examen des systèmes et des données existants, la description du processus métier étape par étape. Le livrable du cadrage est un document écrit : périmètre, rôles utilisateurs, intégrations, données, risques connus et inconnues.
C’est la phase la moins chère du projet, et celle qui fait économiser le plus. Corriger un besoin mal compris dans un document est bien plus facile que dans le code.
Le devis
Le devis s’appuie sur le document de cadrage. Pour chaque lot, il indique ce qui sera fait, combien de temps cela prendra, ce qui est attendu de l’organisation et selon quel critère il sera accepté. Ce qui est hors périmètre est aussi écrit à part. C’est là que l’on précise à qui reviennent le code source et les droits de propriété intellectuelle, et comment se déroulera la maintenance.
La conception
Avant d’écrire du code, nous concevons le modèle de données, la structure des droits et les écrans principaux. Nous montrons les maquettes d’écran aux vrais utilisateurs de l’organisation. Les objections qui apparaissent à ce stade coûtent bien moins cher que celles qui apparaissent plus tard.
Si des données personnelles sont traitées, on décide aussi à ce stade quelles données sont collectées et pourquoi, qui peut les voir et combien de temps elles sont conservées. Ce ne sont pas des fonctionnalités à ajouter plus tard, mais une partie de l’architecture.
Le développement
Nous menons le développement par cycles courts. À la fin de chaque cycle, l’organisation voit une version qui fonctionne dans l’environnement de test. Si quelque chose a été mal compris, on s’en aperçoit en quelques semaines.
Les tests automatisés s’exécutent à chaque modification. Si un test échoue, la version n’avance pas. Nous avons expliqué comment nous le faisons sur notre propre site dans un article à part.
Tests et recette
La recette se fait selon les critères écrits dans le devis. Pour chaque fonctionnalité, des critères concrets du type « dans tel cas, elle donne tel résultat ». L’organisation teste ces critères avec ses propres données, les écarts sont consignés et corrigés.
Quand les critères d’acceptation ne sont pas écrits, le débat « est-ce que ça marche ? » est inévitable. Nous avons expliqué pourquoi dans notre article sur les critères d’acceptation.
La mise en production
La mise en production n’est pas une journée, c’est un petit plan. Si des données doivent être migrées depuis l’ancien système, des migrations d’essai sont faites à l’avance. La façon de revenir en arrière en cas de problème est écrite. Les utilisateurs reçoivent une courte formation et, pendant les premières semaines, les questions obtiennent des réponses rapides.
La maintenance
Après la livraison, les mises à jour de sécurité, les mises à niveau de l’infrastructure et les petites améliorations continuent. Le périmètre de la maintenance et le délai de prise en charge d’un problème sont mis par écrit dès le stade du devis.
Le code source, la documentation et les étapes de déploiement sont remis à l’organisation. Ainsi, si elle veut un jour continuer avec une autre équipe, elle le peut.
Le rôle de l’organisation
À chacune de ces étapes, il faut un interlocuteur côté organisation. Quelqu’un qui connaît le processus métier, qui répond vite aux questions et qui peut tester les versions intermédiaires. Ce qui ralentit les projets, ce n’est le plus souvent pas un problème technique, c’est l’absence de cet interlocuteur.
En bref
Premier rendez-vous, cadrage, devis, conception, développement, recette, mise en production et maintenance. Les étapes s’allongent ou se raccourcissent selon la taille du projet, mais aucune n’est sautée. Écrire à la fin de chaque étape ce qui sera livré évite les surprises à la fin du projet.

## Dix questions à poser pour choisir une société de logiciels

Source : https://kulular.com.tr/fr/publications/choisir-une-societe-de-logiciels

Quand une organisation cherche une société de logiciels, elle a souvent trois ou quatre devis en main. Les prix diffèrent, les délais aussi, mais les textes se ressemblent beaucoup. Tous parlent de « méthode agile », d’« architecture évolutive » et de « solution de bout en bout ».
Ces mots ne distinguent pas une société d’une autre. Ce qui les distingue, ce sont les réponses aux questions posées lors du premier rendez-vous. Dans cet article, je liste ces questions. En tant que société de logiciels, on nous les pose aussi, et nous voulons qu’on nous les pose.
1. Comment définissez-vous le périmètre ?
Une bonne société ne donne pas de prix au premier rendez-vous. Elle cherche d’abord à comprendre ce qu’il faut faire. Qui va l’utiliser, comment le travail se fait aujourd’hui, avec quels systèmes il faut échanger, quelles données seront traitées.
Un prix donné sans ces réponses n’est pas une estimation, c’est un espoir. Si le devis n’explique pas comment le périmètre a été défini, demandez.
2. Écrivez-vous ce que vous ne savez pas ?
Chaque projet commence avec des inconnues. Combien de données viendront de l’ancien système, la documentation d’une intégration est-elle à jour, comment les utilisateurs accueilleront-ils le nouvel écran.
Une société qui les écrit clairement dans son devis vous montre où se trouve le risque. Un devis qui les noie dans un prix ferme rend le risque invisible. Le risque ne disparaît pas, il apparaît simplement plus tard.
3. Sur quelle base accepterons-nous la livraison ?
La plupart des désaccords dans les projets logiciels naissent de la question « est-ce que ça marche ? ». La cause n’est pas technique. Personne n’a écrit au départ ce que « ça marche » veut dire.
Posez cette question vous-même. Pour chaque fonctionnalité, il faut écrire dans quel cas elle est considérée comme terminée. Nous l’avons expliqué en détail dans notre article sur les critères d’acceptation.
4. À quelle fréquence verrons-nous quelque chose qui fonctionne ?
Ne rien voir pendant six mois d’un logiciel livré dans six mois, c’est le terrain des malentendus les plus coûteux. Demandez à voir une version cliquable à intervalles réguliers. Toutes les deux semaines ou tous les mois, mais régulièrement.
5. Qui détiendra le code source et les droits de propriété intellectuelle ?
Le contrat doit répondre clairement à cette question. Le code source est-il cédé à l’organisation, ou seul un droit d’utilisation est-il accordé ? Que se passe-t-il si la société ferme ou si vos chemins se séparent ?
Si la réponse n’est pas écrite, le jour où vous voulez changer de prestataire, il peut ne vous rester qu’un programme qui tourne.
6. Qui assurera la maintenance après la livraison ?
Un logiciel n’est pas terminé le jour de sa livraison. Les systèmes d’exploitation sont mis à jour, des failles de sécurité apparaissent dans les bibliothèques, les utilisateurs expriment de nouveaux besoins. Demandez le périmètre, la durée et le prix de la maintenance dès le stade du devis. Le délai de prise en charge d’une anomalie doit aussi être écrit.
7. Comment protégez-vous les données ?
Si le logiciel traite des données personnelles, l’approche de la société se voit dès le premier rendez-vous. Qui accède à quelles données, est-ce journalisé, où sont les sauvegardes, dans quel pays sont les serveurs, qui sont les sous-traitants ?
Si une société répond « ne vous inquiétez pas », passez à une société qui donne des réponses concrètes. La sécurité des données est une obligation que la loi impose au responsable du traitement. Faire développer le logiciel par un tiers ne supprime pas cette obligation.
8. Qui travaillera sur le projet ?
La personne qui vient au rendez-vous commercial n’est pas forcément celle qui écrira le code. C’est normal. Mais vous voulez savoir qui travaillera sur le projet, qui prendra les décisions et qui vous répondra. Une société qui présente son équipe nommément répond facilement à cette question.
9. Comment avez-vous mené un projet similaire ?
Au lieu d’une liste de références, demandez-leur de raconter un projet. Où ont-ils eu du mal, qu’ont-ils changé, quel a été le résultat. Une société capable de raconter la partie difficile d’un projet l’a vraiment réalisé.
Ils ne pourront peut-être pas citer le nom du client pour des raisons de confidentialité. C’est normal. Mais ils doivent pouvoir raconter le déroulement.
10. Y a-t-il une raison de ne pas faire ce projet ?
La dernière question est un peu inhabituelle, mais elle en dit long. Une bonne société dit parfois : « vous n’avez pas besoin d’un logiciel sur mesure, tel produit existant fera l’affaire ». Parfois aussi : « ce périmètre ne tient pas dans ce budget ». L’entendre montre que vous parlez à quelqu’un qui dit la vérité, au risque de perdre le contrat.
Nous avons traité le choix entre progiciel et logiciel sur mesure dans un article à part.
L’importance de la proximité
Pour une organisation à Ankara, travailler avec une société de logiciels à Ankara est un avantage, mais pas une obligation. Quelques ateliers en présentiel pendant les premières semaines aident à bien comprendre le périmètre. Voir ensemble un système qui tourne sur le terrain aussi.
Ensuite, ce qui compte, ce n’est pas la distance, c’est la régularité de la communication. Des décisions consignées par écrit, des versions présentées régulièrement et des réponses le jour même servent davantage que d’être dans le même bâtiment.
En bref
Ce n’est pas le prix du devis qui distingue une société de logiciels, ce sont ses réponses au premier rendez-vous. Une société qui répond concrètement sur le périmètre, les critères d’acceptation, le code source, la maintenance et la sécurité des données travaille aussi concrètement pendant tout le projet.

## Progiciel ou logiciel sur mesure : comment décider

Source : https://kulular.com.tr/fr/publications/progiciel-ou-logiciel-sur-mesure

Une partie des organisations qui viennent nous voir n’ont en fait pas besoin d’un logiciel sur mesure. Un produit existant bien configuré fait l’affaire. Pour une société de logiciels, le dire revient à perdre un contrat à court terme. À long terme, c’est beaucoup moins cher que de lancer un mauvais projet.
Dans cet article, j’explique comment nous choisissons entre progiciel et logiciel sur mesure.
Première question : votre activité est-elle standard ?
Comptabilité, paie, messagerie, documents bureautiques. Ces tâches se font à peu près de la même façon partout, et la réglementation les rend encore plus semblables. Il existe dans ces domaines des produits mûrs et largement utilisés. Les réécrire à partir de zéro a rarement du sens.
Le processus qui distingue l’organisation des autres, c’est autre chose. La façon dont un hôpital relie les données de ses appareils au parcours clinique, la méthode d’évaluation d’un établissement d’enseignement, un processus de production qu’une entreprise a développé elle-même. Un produit existant ne s’adapte à ces processus que si l’organisation s’adapte au produit.
La règle est simple. Si votre activité est standard, un progiciel. Si ce qui vous distingue se trouve dans le logiciel, du sur mesure.
Calculez le coût sur cinq ans
La première année d’un progiciel paraît en général bon marché. L’installation est rapide, la première facture est petite. S’arrêter là pour comparer est trompeur.
Sur cinq ans, d’autres postes apparaissent. Des licences qui augmentent avec le nombre d’utilisateurs. Des adaptations pour ce que le produit ne couvre pas. Des adaptations à refaire quand la version suivante les casse. Un second processus informel pour ce qui ne rentre pas dans le produit, c’est-à-dire le plus souvent un fichier Excel.
Le logiciel sur mesure a aussi un coût sur cinq ans. Le développement initial, l’hébergement et la maintenance. La différence, c’est que ce coût est plus prévisible et reste sous le contrôle de l’organisation. Nous avons traité ces postes à part dans notre article sur le coût.
Où sont les données ?
La plupart des produits en ligne ont leurs serveurs hors de Turquie. Pour une organisation qui traite des données personnelles, cela constitue au sens de la loi un transfert de données à l’étranger. C’est possible, mais la décision doit être prise en connaissance de cause.
Il y a aussi la question de l’accès aux données. Si vous voulez quitter le produit, sous quel format, en combien de temps et avec quelle exhaustivité pouvez-vous récupérer vos données ? Posez cette question avant de signer. Un produit qui y répond de façon floue vous a déjà rendu dépendant.
La dépendance existe dans les deux sens
Avec un progiciel, la dépendance porte sur le produit. Ce n’est pas vous qui décidez des hausses de prix, des fonctionnalités supprimées ni de l’orientation du produit.
Avec un logiciel sur mesure, il y a aussi une dépendance, cette fois envers la société qui le développe. Si vous n’avez pas le code source, si la documentation n’est pas écrite et si une autre équipe ne peut pas lire le code, changer de prestataire devient presque impossible. C’est pourquoi, pour un logiciel sur mesure, il faut exiger que le code source, la documentation et les étapes de déploiement soient remis à l’organisation.
Le plus souvent, la réponse est les deux
Les architectures les plus saines que nous voyons sont mixtes. Les tâches standard tournent sur des produits existants. Le processus qui distingue l’organisation tourne sur un logiciel sur mesure. Entre les deux, une intégration propre évite de saisir deux fois les mêmes données.
Dans cette architecture, le périmètre du logiciel sur mesure se réduit et il est livré plus vite. Les produits existants sont aussi libérés des tâches pour lesquelles ils peinent.
Quand nous disons de ne pas développer
Quand une organisation vient nous voir et que nous constatons que son besoin peut être couvert par un produit courant, nous le lui disons. Si nécessaire, nous l’aidons à relier ce produit à ses systèmes existants. Nous recommandons le sur mesure là où il fait vraiment la différence.
En bref
Un progiciel pour l’activité standard, du sur mesure pour ce qui distingue l’organisation. Comparez le coût sur cinq ans, pas sur la première année. Tenez compte aussi de l’endroit où se trouvent les données et de la façon de les récupérer en partant.

## Ce qui détermine le coût d’un logiciel sur mesure

Source : https://kulular.com.tr/fr/publications/cout-d-un-logiciel-sur-mesure

« Combien coûte ce logiciel ? » est la question qu’on nous pose le plus souvent. La réponse n’est pas un chiffre unique, et le dire ressemble à une esquive. Ce n’en est pas une. Un chiffre donné sans connaître les postes qui déterminent le coût est soit trop élevé, soit un chiffre qui augmentera en milieu de projet.
Dans cet article, j’explique quels postes déterminent le coût d’un logiciel sur mesure et ce qu’il faut regarder en lisant un devis. Je ne donne pas de chiffres, parce que chaque projet est différent. Mais voir d’où vient le chiffre rend la comparaison des devis beaucoup plus simple.
Le nombre d’écrans est une mesure trompeuse
On pense souvent le coût d’un logiciel en nombre d’écrans. Un écran de connexion, une liste, un formulaire, un rapport. Or les écrans ne sont que la partie visible du coût.
Deux formulaires d’apparence identique peuvent avoir des coûts très différents. L’un écrit les données saisies dans une table. L’autre vérifie ces mêmes données, les montre à des personnes différentes selon leurs droits, les envoie à un autre système et journalise chaque modification. Ce sont les règles derrière l’écran qui déterminent le coût.
Les intégrations
Un logiciel fonctionne rarement seul. Système comptable, authentification, paiement, messagerie, anciens systèmes de l’organisation ou service public. Chaque connexion est un travail à part.
Se connecter à un service bien documenté, doté d’une interface solide, peut prendre quelques jours. Se connecter à un ancien système mal documenté et sans environnement de test peut prendre des semaines. Demander au stade du devis la documentation et les possibilités de test de chaque intégration clarifie la partie la plus incertaine du coût.
Les données et leur migration
Si le nouveau logiciel ne démarre pas avec une base de données vide, il faudra migrer les données de l’ancien système. La plupart des devis y consacrent une seule ligne, et c’est l’un des endroits où les projets dérapent le plus souvent. Nous avons expliqué pourquoi dans notre article sur la migration des données.
Sécurité et réglementation
Un logiciel qui traite des données de santé, des données d’élèves ou des données financières demande plus de travail qu’un outil interne d’apparence identique. Contrôle d’accès par rôle, journaux d’accès, chiffrement, application des durées de conservation, suppression et anonymisation. Ce sont des éléments difficiles à ajouter après coup. Les inclure dès le départ est à la fois moins cher et plus sûr.
L’incertitude
Chaque projet comporte des inconnues. Un bon devis les écrit à part et dit comment elles seront traitées. Un mauvais devis soit ajoute l’incertitude au prix sans le dire, soit n’en tient pas compte du tout. Le second cas est plus dangereux, car l’écart apparaît en milieu de projet sous forme de facture supplémentaire.
La meilleure façon de réduire l’incertitude est de placer une courte phase de cadrage au début du projet. Pendant cette phase, le périmètre, les intégrations et les données se précisent. Le développement proprement dit est ensuite chiffré sur une base plus solide.
Tests et recette
Les tests sont le poste le plus exposé aux coupes. Quand on les coupe, c’est aussi le poste dont on paie le prix le plus tard. Tests automatisés, tests d’acceptation et essais avec de vrais utilisateurs. Si l’effort consacré aux tests n’apparaît pas dans le devis, soit cet effort ne sera jamais fourni, soit il retombera sur votre équipe.
Après la livraison
Le coût d’un logiciel ne s’arrête pas le jour de la livraison. L’hébergement, les sauvegardes, les mises à jour de sécurité, la mise à niveau des bibliothèques utilisées et les petites améliorations continuent. Voir ces postes séparément au stade du devis évite les surprises à la fin de la première année.
En lisant un devis
Quand vous comparez plusieurs devis, écrivez côte à côte ce que chacun couvre. Les intégrations sont-elles incluses, la migration des données est-elle incluse, quelle part pour les tests, comment la maintenance est-elle chiffrée, à qui revient le code source. La plupart des écarts de prix montrent que ce n’est pas le même travail qui a été chiffré.
En bref
Ce ne sont pas les écrans qui déterminent le coût d’un logiciel sur mesure, ce sont les règles derrière les écrans, les intégrations, les données, la sécurité, les tests et la maintenance. Un devis qui écrit clairement ces postes, même s’il paraît plus élevé, revient souvent moins cher.

## Comment construire un site web d’entreprise : notes sur notre propre site

Source : https://kulular.com.tr/fr/publications/comment-nous-avons-construit-ce-site

Le site d’une entreprise de logiciels est le premier logiciel qu’elle écrit. Le visiteur qui l’ouvre ne voit pas le code, mais il en voit le résultat. Si la page s’ouvre lentement, si une phrase en turc traîne dans une autre langue, si le formulaire de contact échoue en silence, il en tire des conclusions sur le travail de l’entreprise.
C’est pourquoi nous avons construit ce site non comme une brochure, mais comme un petit produit. J’écris ci-dessous quelles décisions nous avons prises, pourquoi, et où nous nous sommes trompés.
Génération statique
Le site est écrit avec Next.js. Dans la première version, les pages étaient régénérées sur le serveur à chaque requête. La cause était une ligne innocente : la mise en page racine lisait l’en-tête de la requête pour trouver la langue. Next considère comme dynamique toute page où il voit cela.
Résultat : Cloudflare ne pouvait mettre aucune page en cache. Chaque visite remontait jusqu’au serveur chez Hetzner. En local, le temps jusqu’au premier octet était de quelques millisecondes. Le code n’était donc pas lent. Le problème allait apparaître à grande échelle.
La solution a été de déduire la langue de l’adresse, et non de la requête. Chaque langue a sa propre mise en page racine, et la langue découle du dossier où se trouve la page. Aujourd’hui, les quelque trois cents pages sont toutes générées une seule fois, à la compilation.
Sept langues et la cohérence
Le site est publié en turc, anglais, français, portugais, allemand, espagnol et arabe. La traduction en elle-même est la partie facile. Le difficile, c’est qu’un texte modifié doit changer à sept endroits à la fois.
La plupart des erreurs trouvées lors des premiers contrôles venaient du même schéma. Une longue chaîne de conditions choisissait le texte selon la langue. Quand elle oubliait une langue, elle tombait en silence dans la dernière branche, et cette dernière branche était généralement le turc. C’est ainsi qu’une phrase en turc apparaissait au milieu d’une page en français.
Nous avons réglé cela avec une fonction utilitaire. Chaque endroit qui choisit un texte doit fournir les sept langues à la fois. S’il en manque une, le code ne compile pas. L’erreur est détectée avant la mise en ligne.
Le titre académique posait un problème semblable. Dans une traduction, le titre « Doç. Dr. » était devenu « professeur ». Désormais, le titre n’est traduit dans aucune langue. Il est repris de la fiche en turc, et un test le vérifie à chaque push.
Les tests
Nous n’avons pas mis en place un framework de test lourd. Nous avons écrit neuf tests avec le module de test intégré de Node. Chacun détecte une erreur que nous avons réellement rencontrée.
Parmi eux : le titre doit rester identique dans toutes les langues, aucun texte ne doit contenir de tiret cadratin, le nom de la marque ne doit pas être traduit, chaque article en turc doit avoir son équivalent dans les six autres langues, et les textes juridiques ne doivent pas être résumés à la traduction. Le dernier test est grossier mais il fonctionne. Si la page juridique d’une langue fait moins de soixante pour cent de la version turque, elle a très probablement été résumée.
À chaque push sur GitHub, la vérification des types, le lint, ces tests et la compilation de production s’exécutent. Si l’un d’eux échoue, la version n’est pas mise en ligne.
La sécurité
La politique de sécurité du contenu est stricte. Aucun script, aucune police, aucune image ne peut être chargé depuis un domaine externe. Les polices viennent de notre propre serveur. Le navigateur du visiteur n’envoie donc aucune requête à un tiers en ouvrant la page. Google Analytics n’est chargé que si le visiteur donne son consentement.
L’écran de protocole de travail de la page d’accueil envoie à un modèle de langage le texte saisi par le visiteur. C’est l’endroit du site le plus facile à détourner. Quelqu’un qui voudrait utiliser gratuitement un modèle payant pourrait appeler directement le point d’accès. Nous l’en empêchons avec plusieurs couches : la vérification que la requête vient bien de notre page, un jeton signé à usage unique et de courte durée, une limite horaire et quotidienne par adresse, un plafond quotidien pour l’ensemble du site et une limite sur le nombre de requêtes qui peuvent atteindre le modèle en même temps.
Le déploiement
Le code est sur GitHub. Coolify tourne sur le serveur chez Hetzner. À chaque push sur la branche principale, il recompile le site sous forme d’image Docker et le met en ligne. Un déploiement prend environ deux minutes et demie.
Cloudflare se trouve devant. Depuis le passage à la génération statique, le HTML peut lui aussi être mis en cache, et les pages y restent jusqu’à une heure.
Où nous nous sommes trompés
Le cache a été une source de vitesse, mais aussi d’illusion. Nous avons mis en ligne une nouvelle version. Coolify a indiqué un succès, mais la page d’accueil s’affichait dans son ancien état. La raison était simple. Cloudflare ne demandait pas la nouvelle copie tant que la sienne n’avait pas expiré.
La bonne solution est de vider le cache automatiquement à la fin de chaque déploiement. Une mise en ligne n’est terminée que lorsqu’elle l’est là où le visiteur la voit, pas seulement sur le serveur.
Il y a aussi l’accessibilité. L’analyse automatique ne trouvait aucune erreur sur les pages. Pourtant, les petites étiquettes de la page d’accueil étaient posées sur une photo semi-transparente, et l’outil d’analyse ne sait pas mesurer le contraste sur une photo. Nous avons mesuré à part les pixels derrière les étiquettes. Le rapport tournait autour de 3:1. En atténuant un peu la photo et en fonçant les étiquettes d’un ton, il est passé au-dessus de 5:1. Même quand l’outil dit « aucune erreur », il faut regarder.
Pourquoi nous le racontons
Dire à un client « nous livrons des logiciels qui fonctionnent » est facile. En écrivant clairement ce que nous avons fait sur ce site, on voit aussi plus facilement sur quoi repose cette phrase.

## Un agent d’IA qui répond aux e-mails : comment nous avons fixé les limites de KAI

Source : https://kulular.com.tr/fr/publications/les-limites-de-kai

KAI est le membre IA de notre équipe. Elle figure sous son nom sur la page de l’équipe, car nous ne voulions pas cacher notre usage de l’intelligence artificielle en coulisses. Mais donner un nom à une IA est la partie facile. La vraie question, c’est la part du travail que vous lui confiez.
Aujourd’hui, KAI lit les e-mails qui arrivent à l’entreprise. Elle répond elle-même à ceux de routine et planifie des réunions. Pour les autres, elle ne prépare qu’un brouillon, et c’est un membre de l’équipe qui décide de l’envoyer ou non. Cet article explique où nous avons tracé cette ligne et pourquoi.
Les deux options faciles étaient mauvaises
Deux options viennent d’abord à l’esprit. La première : l’agent envoie tout lui-même. La seconde : chaque réponse est validée par un humain avant l’envoi.
La première est clairement risquée. Un modèle de langage peut inventer un prix ou une date de livraison avec beaucoup d’assurance. L’interlocuteur le lit comme un engagement de l’entreprise.
La seconde semble sûre, mais en pratique elle ne fonctionne pas. Nous l’avions aussi expliqué dans un autre article sur la gouvernance de l’IA. Dans un système où chaque réponse doit être validée, le taux de validation finit par approcher les cent pour cent. La personne qui valide cesse de lire le texte. Sur le papier, il y a une supervision humaine. En réalité, c’est le système qui décide.
Sur quoi nous avons tracé la ligne
Pour considérer un e-mail comme de routine, nous avons posé deux questions. La réponse est-elle connue à l’avance ? Si elle est fausse, peut-on la corriger facilement ?
Si la réponse est oui aux deux, la tâche est de routine. Proposer une heure de réunion, accuser réception d’un document, répondre à une question générale avec les informations du site entrent dans cette catégorie. Si KAI propose une mauvaise heure, l’interlocuteur la corrige dans le message suivant et personne n’en pâtit.
Si la réponse est non à l’une des deux, la tâche n’est pas de routine. Tout échange qui porte sur un prix, un périmètre, un contrat, une date de livraison ou des données personnelles entre dans cette catégorie. Ici, KAI prépare un brouillon, mais le message ne part pas sans la décision d’un membre de l’équipe.
L’intérêt de cette distinction est de garder la validation humaine rare mais significative. Chaque message soumis à validation demande vraiment réflexion. La personne qui valide sait que ce qu’elle a sous les yeux est important.
Indiquer l’IA dans la signature
La signature de chaque e-mail envoyé par KAI indique que le message a été rédigé par un système d’intelligence artificielle. Nous le faisons pour deux raisons.
La première est l’honnêteté. L’interlocuteur ne doit pas croire qu’il écrit à un humain et accorder sa confiance en conséquence. La seconde est la réglementation. Le règlement (UE) 2024/1689 sur l’intelligence artificielle exige que les personnes sachent qu’elles interagissent avec une IA. Pour nos interlocuteurs en Europe, c’est une obligation. Pour ceux en Turquie, c’est aussi une bonne habitude.
Ce qu’elle ne peut pas faire
KAI n’a aucun pouvoir de signature dans l’entreprise. Elle ne peut pas faire d’offre, conclure un contrat ni interpréter la réglementation. Ces limites ne figurent pas seulement dans une liste de règles. Elles sont aussi inscrites dans les outils que l’agent peut utiliser. Quand vous ne donnez pas un droit à un agent, vous n’avez pas non plus à lui faire confiance pour ne pas s’en servir.
KAI accède à un modèle de langage via OpenRouter. Cela signifie que les échanges sont transmis à un prestataire situé à l’étranger. Nous l’avons expliqué séparément dans notre notice d’information. Nous y demandons aussi de ne pas envoyer par e-mail d’informations confidentielles, de données personnelles sensibles ni de secrets d’affaires.
Là où cette conception est mise à l’épreuve
La ligne entre routine et hors routine n’est pas toujours nette. « Je ne peux pas venir à la réunion, un autre jour serait-il possible ? » est un message de routine. « Je ne peux pas venir à la réunion parce que nous suspendons le projet » ne l’est pas. Les deux commencent par la même phrase.
C’est pourquoi, en cas de doute, le comportement par défaut est de préparer un brouillon. KAI ne considère pas comme de routine un message dont elle n’est pas sûre. Se tromper dans ce sens, c’est-à-dire laisser inutilement une tâche à un humain, coûte moins cher que se tromper dans l’autre.
Ce que nous transposons aux projets clients
Le critère que nous appliquons à notre propre travail est aussi transposé aux systèmes que nous construisons pour nos clients. Nous n’activons ni ne désactivons l’autonomie d’un agent avec un seul interrupteur. Nous classons les tâches selon que la réponse est connue à l’avance ou non, et selon que l’erreur est réversible ou non. Selon la catégorie, l’agent soit termine la tâche, soit laisse un brouillon.
Ce critère n’est pas parfait. Mais nous pouvons écrire clairement où il s’arrête, et une limite que nous pouvons écrire, nous pouvons la contrôler.

## Migrer les données vers un nouveau logiciel : pourquoi nous comptons les enregistrements trois fois

Source : https://kulular.com.tr/fr/publications/migrer-les-donnees-d-un-ancien-systeme

Quand une organisation passe à un nouveau système, elle parle surtout de ses fonctionnalités. Les écrans, les rapports, l’application mobile. La manière de migrer les données de l’ancien système passe généralement en dernier, avec un simple « on fera un transfert ».
C’est pourtant là que les projets coincent vraiment. Le code fonctionne, les écrans sont prêts, mais une partie des fiches clients arrive incomplète, et personne ne sait combien ni pourquoi.
Dans cet article, j’explique ce que nous vérifions avant, pendant et après la migration.
D’abord l’inventaire
Nous ne commençons pas une migration par une première ligne de code, mais par une liste. Quelles tables existent dans l’ancien système, combien d’enregistrements contient chacune, que signifie chaque champ, lesquels ne sont plus utilisés.
La surprise la plus fréquente dans cette liste, c’est la même information stockée à deux endroits. L’adresse du client figure à la fois dans la table des clients et dans celle des factures, et les deux ne concordent pas. Décider laquelle fait foi n’est pas une décision technique. C’est à l’organisation de la prendre. Il faut poser la question avant la migration.
La deuxième surprise, c’est que l’ancien système soit un fichier Excel. Dans Excel, tout champ qui n’est pas encadré par une règle est un champ où quelqu’un a un jour écrit autre chose « provisoirement ». On trouve des lignes avec « aucune » dans la colonne des dates, des cellules avec deux numéros dans la colonne des téléphones.
La correspondance des champs
Deux systèmes ne stockent pas les données de la même façon. L’ancien peut avoir un seul champ « nom et prénom » quand le nouveau en a deux. La ville, saisie en texte libre dans l’ancien, peut être choisie dans une liste dans le nouveau.
Pour chaque champ, nous écrivons une règle de correspondance : l’ancien champ, le nouveau champ et la conversion entre les deux. Les enregistrements qui ne respectent pas la règle ne sont pas corrigés en silence. Ils sont placés dans une liste à part. Nous examinons cette liste un par un avec l’organisation.
La correction silencieuse est tentante, mais c’est la pire chose à faire dans une migration. Un enregistrement erroné l’était déjà dans l’ancien système. S’il est corrigé au jugé pendant la migration, il devient dans le nouveau système un enregistrement qui paraît juste mais qui est faux. Personne ne s’en apercevra plus jamais.
Compter trois fois
Pour pouvoir dire « terminé » à la fin d’une migration, nous comptons les enregistrements à trois endroits.
Le premier est la source. Le nombre d’enregistrements à migrer dans l’ancien système, table par table.
Le deuxième est le transfert. Le nombre d’enregistrements que le script de migration a lus, convertis et mis de côté dans la liste à part.
Le troisième est la cible. Le nombre d’enregistrements réellement créés dans le nouveau système.
La source doit être égale à la somme des enregistrements transférés et des enregistrements écartés. Les transférés doivent être égaux à la cible. Si ces deux égalités ne tiennent pas, la migration n’est pas terminée, aussi faible que soit l’écart. Un écart de quelques centaines d’enregistrements, c’est l’historique de quelques centaines de clients perdu.
Que les chiffres concordent ne suffit pas. Les chiffres peuvent concorder alors que le contenu est altéré. C’est pourquoi nous ouvrons côte à côte, dans les deux systèmes, des enregistrements choisis au hasard et nous les comparons champ par champ. Pour les champs critiques comme les montants et les dates, nous calculons aussi séparément des totaux et des valeurs de synthèse des deux côtés.
Migration d’essai et plan de retour arrière
Nous ne faisons pas la vraie migration pour la première fois le jour J. Nous effectuons d’abord au moins deux migrations d’essai sur une copie des données. À chaque essai, nous mesurons la durée, examinons les enregistrements écartés et corrigeons les règles de correspondance.
Avant la vraie migration, un plan de retour arrière est mis par écrit. Que faire si la migration s’interrompt à mi-chemin ou si les chiffres ne concordent pas, jusqu’à quel point on peut revenir à l’ancien système, qui prendra cette décision. Quand ces questions sont posées le jour de la migration, on y répond dans la précipitation.
Les deux systèmes ensemble, pour une courte période
Quand c’est possible, l’ancien système reste ouvert en lecture seule pendant une courte période après l’ouverture du nouveau. Si un enregistrement semble manquant ou erroné, on peut consulter l’ancien système et comparer.
La fin de cette période est fixée dès le départ. Sinon, les deux systèmes cohabitent pendant des mois, et le débat sur celui qui fait foi recommence.
Ne pas migrer est aussi une décision
Tout ancien enregistrement n’a pas à être migré vers le nouveau système. Migrer des données dont la durée de conservation a expiré oblige l’organisation à continuer de les conserver inutilement. Pour les données personnelles, cela peut en plus devenir un manquement à une obligation.
La migration est un bon moment pour faire ce tri. Nous identifions les enregistrements dont la durée de conservation a expiré, nous les excluons de la migration avec l’accord de l’organisation et nous consignons la suppression. Le nouveau système démarre ainsi sur une base propre.
En bref
Une migration de données n’est pas un simple transfert, c’est un petit projet. Une migration menée sans inventaire, sans correspondance des champs, sans comptage en trois étapes, sans migration d’essai et sans plan de retour arrière fait perdre la confiance dans le nouveau système dès son premier jour.

## Quand le contrôle humain ne fonctionne pas dans un système d’IA

Source : https://kulular.com.tr/fr/publications/supervision-ia

Quand nous développons un système d’IA pour une organisation, l’une des premières demandes est la validation humaine. Cet article explique comment savoir si cette validation fonctionne réellement dans le système.
Quand on parle de gouvernance de l'intelligence artificielle, la phrase la plus fréquemment entendue est celle-ci. « Il y a une approbation humaine, la décision n'est pas laissée à la machine. »
Quand j'entends cette phrase, je ne pose qu'une seule question. Quel est votre taux d'approbation ?
Aucune réponse n'arrive, parce que ce n'est pas mesuré. Dans les quelques endroits où c'est mesuré, le résultat dépasse généralement quatre-vingt-dix-huit pour cent. C'est-à-dire que la personne chargée de la supervision s'oppose au modèle une fois sur cinquante décisions. Dire qu'il existe une supervision humaine dans ce tableau est formellement exact mais fonctionnellement faux. C'est en réalité le système qui décide, la personne ne fait que signer.
Pourquoi le bouton d'approbation ne fonctionne pas
La cause n'est pas la mauvaise foi, mais la conception.
Si l'on montre à un utilisateur trois cents recommandations par jour en lui demandant d'approuver chacune, cet utilisateur s'automatise rapidement. Si le taux de justesse du modèle est élevé, cela s'accélère encore, car même dans les quelques cas où il rejette, le modèle a généralement raison, et l'utilisateur cesse de faire confiance à son propre jugement.
Cela s'appelle dans la littérature la confiance excessive envers l'automatisation, et c'est un phénomène bien connu. Autrement dit, plus le système fonctionne bien, plus la supervision humaine s'affaiblit. C'est un fait dont il faut tenir compte dans la conception de la supervision.
Les trois conditions qui rendent la supervision significative
Pour que la supervision soit fonctionnelle, trois éléments doivent être réunis simultanément.
La personne chargée de la supervision doit pouvoir voir le fondement de la recommandation. Si l'on ne montre pas à partir de quelles données d'entrée le modèle est parvenu à ce résultat, la personne ne peut évaluer que le résultat, et pour l'évaluer elle devrait tout redécider elle-même depuis le début. Cela rend la supervision pratiquement impossible.
Le rejet doit être sans coût. Un utilisateur à qui le rejet impose de remplir un formulaire supplémentaire, de rédiger une justification et d'obtenir l'accord de sa hiérarchie choisit de ne pas rejeter. Le parcours de rejet doit être au moins aussi simple que celui de l'approbation.
Le rejet doit avoir une conséquence. Si les recommandations rejetées sont simplement notées quelque part sans que personne ne les regarde, la personne chargée de la supervision le remarque et finit par s'en désintéresser. Faire en sorte que les cas rejetés nourrissent l'amélioration du modèle maintient la supervision vivante.
Il n'existe pas de supervision que l'on ne mesure pas
Même une fois ces trois conditions réunies, la mesure reste nécessaire.
Au moins trois indicateurs doivent être suivis. Le taux de rejet, le temps moyen consacré par décision et le taux de justesse ultérieur des décisions rejetées. Si le temps par décision est tombé à l'ordre de la seconde, cela signifie qu'aucune supervision n'est exercée. Si le taux de rejet s'approche de zéro, la conclusion est la même.
Très peu d'organisations ont une réponse lorsque ces indicateurs sont demandés lors d'un audit. Pourtant, ce ne sont pas des mesures difficiles, elles se déduisent de données que le système produit déjà de lui-même.
Le droit de contestation détermine l'architecture
L'article 11 de la loi n° 6698 reconnaît à la personne le droit de contester un résultat défavorable résultant exclusivement de l'analyse par des systèmes automatisés.
La conséquence technique de cette disposition est directe. Lorsqu'une contestation survient, vous devez pouvoir montrer comment la décision a été prise. Si vous ne le pouvez pas, vous ne pouvez pas défendre la décision.
Il en découle cette règle architecturale. Dans un processus produisant des conséquences pour une personne, un modèle qui ne produit pas de justification ne peut pas être utilisé. Cela doit être inscrit dès le départ comme une contrainte dans le choix du modèle. Ajouter l'explicabilité après coup n'est pas possible dans la plupart des architectures.
Conserver des journaux ne suffit pas, il faut enregistrer la bonne chose
Quand on parle de piste d'audit, on pense d'abord à tenir un journal, mais c'est le contenu de ce journal qui est déterminant.
Pour qu'une décision puisse être examinée par la suite, cinq éléments doivent être enregistrés ensemble. Les données entrées dans le système, la version du modèle, le résultat produit, la justification sur laquelle repose ce résultat, et la décision finale prise par la personne. Si ces cinq éléments sont conservés dans des systèmes séparés, ils ne peuvent plus être recoupés par la suite. Si la version du modèle n'a pas été enregistrée, il devient impossible, des mois plus tard, de répondre à la question de ce que disait le modèle à cette date.
La version du modèle non enregistrée est, en pratique, la lacune que je constate le plus souvent. Le modèle est mis à jour, on essaie d'expliquer d'anciennes décisions avec le nouveau modèle, et cela ne colle pas.
Il faut montrer la différence entre la certitude et l'incertitude
Un dernier point. Le système doit montrer de manière distinguable le résultat qu'il produit avec une faible confiance de celui qu'il produit avec une confiance élevée.
En l'absence de cette distinction, l'utilisateur fait confiance à tous de la même manière et ne reçoit aucun avertissement précisément là où l'erreur est la plus probable. Pourtant, l'incertitude propre au modèle peut le plus souvent être mesurée. Porter cette mesure jusqu'à l'interface est l'amélioration la moins coûteuse et la plus efficace de la supervision.
S'il fallait choisir une seule chose à faire aujourd'hui dans un projet d'intelligence artificielle, ce serait celle-là que je choisirais.

## La clause la plus souvent oubliée d’un projet logiciel : le critère d’acceptation

Source : https://kulular.com.tr/fr/publications/contrats-developpement-logiciel

En tant que société de logiciels, c’est l’un des premiers sujets que nous abordons dans chaque projet. Un projet qui démarre sans critère d’acceptation écrit est un projet où chacun attend quelque chose de différent jusqu’au jour de la livraison.
Lorsqu'un dossier de litige logiciel s'ouvre, les parties débattent généralement de ceci. Le logiciel fonctionne-t-il ou non.
La raison pour laquelle ce débat ne peut être tranché n'est pas technique. Le contrat ne précise pas ce que signifie « fonctionner ». En l'absence de critère de recette, le développeur affirme avoir livré, le client affirme n'avoir rien reçu, et chacun a raison selon son propre critère.
Cette seule lacune est le dénominateur commun des litiges logiciels que j'ai vus.
Comment rédiger le critère de recette
La recette est le moment qui produit la conséquence juridique de la livraison. C'est également à partir de là que commence à courir le délai de responsabilité pour vices. Autrement dit, l'incertitude sur cette date entraîne aussi l'incertitude sur le moment où la responsabilité prend fin.
Une clause de recette qui fonctionne comprend les éléments suivants. La liste des tests de recette, l'environnement dans lequel le test sera exécuté, qui l'exécute, le délai d'objection, et la règle selon laquelle la recette est réputée acquise si aucune objection n'arrive dans ce délai.
L'élément le plus souvent oublié est l'environnement de test. Un logiciel qui fonctionne sur la machine du développeur peut ne pas fonctionner dans l'environnement du client, et à ce moment-là on discute de qui en est responsable. Si l'environnement est défini dans le contrat, ce débat ne se produit pas.
Subordonner le critère de recette à la satisfaction subjective est, quant à lui, le pire choix. Une recette conditionnée « à la satisfaction du client » crée une obligation sans limite de durée, et le travail du développeur ne se termine jamais.
Les droits de propriété intellectuelle ne sont pas cédés automatiquement
La deuxième erreur fréquente est la présomption de propriété. Le client pense qu'en contrepartie du prix payé, il est propriétaire du code. Juridiquement, ce n'est pas le cas.
Les programmes d'ordinateur sont protégés en tant qu'œuvre au titre de la loi n° 5846, et, sauf convention contraire, les droits patrimoniaux restent au titulaire de l'œuvre. La cession doit être expressément prévue, faite par écrit, et les droits cédés doivent être énumérés un par un. Une formule générale telle que « tous les droits sont cédés » reste ouverte à la contestation.
Il faut par ailleurs distinguer trois catégories. Le code écrit spécifiquement pour le client est généralement cédé. Les composants préexistants du développeur ne sont pas cédés, ils sont concédés sous licence, et l'étendue ainsi que la durée de cette licence sont rédigées séparément. Les composants open source sont soumis à leurs propres licences, et la liste de ceux qui sont utilisés doit être annexée au contrat.
Lorsque ces trois catégories ne sont pas distinguées, voici ce qui se produit. Le client croit être propriétaire de l'intégralité du code, le développeur continue d'utiliser sa propre bibliothèque dans un autre projet, et le problème n'est remarqué qu'au moment d'un litige.
Un contrat sans gestion des changements ne fonctionne pas
Aussi bien rédigé que soit le cahier des charges, des demandes de changement surviennent en cours de projet. Si le contrat ne précise pas comment cette demande sera traitée, chaque demande se transforme en négociation.
Une clause qui fonctionne répond aux questions suivantes. À qui et sous quelle forme la demande est-elle transmise. Par qui et en combien de jours l'analyse d'impact est-elle réalisée. Comment l'effet sur le prix et le calendrier est-il calculé. Avec la signature de qui l'approbation est-elle donnée. Que devient une demande non approuvée.
Lorsque ces cinq questions trouvent réponse, le changement cesse d'être une crise pour devenir un processus.
La qualité de sous-traitant de données naît sans qu'on s'en aperçoive
Si le développeur accède à des données personnelles du client, il acquiert la qualité de sous-traitant au sens de la loi n° 6698. Cette qualité est souvent acquise sans que personne ne s'en rende compte.
Le cas le plus fréquent est l'utilisation de données réelles dans l'environnement de test. Une copie de la base de données de production est transférée vers l'environnement de test, les développeurs travaillent avec, et à partir de ce moment naît une relation de traitement de données. Si le contrat ne contient aucune clause à ce sujet, cette relation se déroule sans fondement juridique.
La solution la plus propre consiste à ne jamais laisser cette situation se produire. Tester avec des données masquées ou synthétiques n'est pas techniquement difficile et élimine en grande partie le risque. Si l'accès à des données réelles est réellement indispensable, l'objet, la durée et la finalité du traitement, l'assujettissement du développeur aux instructions, le recours à des sous-traitants ultérieurs, les mesures de sécurité, ainsi que la restitution ou la destruction des données à la fin du contrat doivent être régis par écrit.
La maintenance est un contrat distinct
Enfin, la maintenance et le support. Il s'agit d'une prestation distincte du développement et qui doit être régie séparément.
Ce qu'il faut rédiger, ce n'est pas le délai d'intervention, mais la classification des incidents. Si l'on ne définit pas quel incident relève de quelle classe, chaque incident est réclamé avec la priorité la plus élevée. Une fois les classes définies, le délai d'intervention et de résolution est rédigé séparément pour chacune.
Il y a aussi la question de la mesure. Un engagement de niveau de service qui n'est pas mesurable reste sans sanction en cas de manquement. La manière dont cette mesure sera effectuée, et sur la base du relevé de qui, doit figurer dans le contrat.
Qui doit rédiger le contrat
L'ensemble de ces clauses exige que le droit et l'ingénierie décident conjointement. L'avocat ne peut pas rédiger seul le critère de recette, car il ne sait pas ce qui est testable. L'ingénieur ne peut pas rédiger seul la cession des droits de propriété intellectuelle.
La partie qui aborde la négociation du contrat sans équipe technique finit par accepter des clauses qui se révéleront inapplicables par la suite. Une clause inapplicable, lorsqu'un litige survient, se comporte comme si elle n'avait jamais existé.

## Un service cloud à l’étranger, c’est aussi un transfert de données

Source : https://kulular.com.tr/fr/publications/transferts-internationaux-donnees

Quand on choisit l’infrastructure d’un logiciel, l’emplacement du serveur est souvent discuté sous l’angle du prix et de la vitesse. Ce choix a aussi un volet transfert de données, et il n’est pas facile à changer après coup.
Demandez à une organisation si elle transfère des données à l'étranger, la réponse est en général non. Demandez ensuite quels services elle utilise, et une liste apparaît : hébergement cloud, messagerie, logiciel de support client, un outil d'analyse, un prestataire de paiement, un service de sauvegarde.
Les serveurs de la plupart de ces services ne sont pas en Türkiye. La vraie réponse était donc oui, et l'organisation ne le savait pas.
Ce malentendu vient du mot "transfert" lui-même, qui évoque un acte délibéré : prendre un fichier et l'envoyer. Or, conserver des données sur un système à l'étranger, ou les y faire traiter, est aussi un transfert. Nul besoin de chercher un acte d'envoi distinct.
Voir où un transfert commence réellement
L'article 9 de la loi turque n° 6698 régit les transferts vers l'étranger. En pratique, la difficulté ne tient pas à la disposition elle-même, mais à déterminer quand un transfert a effectivement eu lieu.
Les trois situations suivantes donnent toutes lieu à un transfert : des données hébergées sur un serveur à l'étranger, une équipe à l'étranger pouvant accéder au système à des fins de support, et des données traitées à l'étranger dont le résultat est renvoyé. La troisième est celle qu'on oublie le plus souvent. Si vous utilisez un service d'analyse de texte situé à l'étranger, le texte que vous envoyez y est traité. Que le résultat vous revienne ne signifie pas qu'aucun transfert n'a eu lieu.
Notre propre site présente exactement cette caractéristique. Le champ de texte libre de la page d'accueil envoie le texte saisi à un prestataire à l'étranger pour analyse. C'est pourquoi notre notice de protection des données lui consacre une section à part, et un visiteur peut parcourir tout le reste du site sans jamais utiliser ce champ. Faire en sorte qu'aucun transfert ne se produise lorsque la fonction n'est pas utilisée a été une décision de conception au même titre que la fonction elle-même.
La colonne manquante dans l'inventaire
La plupart des inventaires de données mentionnent la catégorie, la finalité et la durée de conservation. La colonne manquante est celle-ci : dans quel pays ces données se trouvent-elles physiquement ?
Une fois cette colonne ajoutée, le tableau change. Une partie des données que l'organisation pensait conserver dans son propre centre de données se révèle en réalité à l'étranger. Les sauvegardes sont ce qu'on oublie le plus souvent, car le service de sauvegarde est en général confié à un prestataire distinct que personne ne pense à localiser.
Lors de l'élaboration de l'inventaire, il faut interroger directement le prestataire. Si le contrat comporte un engagement sur la résidence des données, il faut l'obtenir par écrit. À défaut, le prestataire peut modifier cette disposition unilatéralement sans que vous en soyez informé.
La chaîne de sous-traitants
Le second niveau est encore moins visible. Le prestataire que vous utilisez peut lui-même dépendre d'autres prestataires pour sa propre infrastructure.
Vous utilisez un logiciel de support client ; ce logiciel fonctionne chez un hébergeur cloud ; il fait appel à un autre service pour la recherche ; et se connecte à un troisième pour l'envoi de notifications. Vos données circulent dans toute cette chaîne.
Il n'est pas possible de contrôler entièrement cette chaîne, mais il est possible de la rendre visible. Le contrat doit imposer une notification en cas de recours à des sous-traitants et accorder un droit d'opposition à tout changement. La plupart des prestataires professionnels le proposent déjà, il suffit de le demander.
Que faire
La première étape consiste à établir un inventaire des services : le nom de chaque service externe utilisé, à quoi il sert, à quelles catégories de données personnelles il peut accéder et où se trouvent ses serveurs.
Une fois ce tableau établi, trois options s'offrent à vous : remplacer le service par une alternative hébergée en Türkiye, migrer vers la région turque du prestataire s'il en a une, ou donner au transfert une base juridique adéquate au moyen de l'un des mécanismes prévus par la loi.
Les trois ont un coût, et le bon choix dépend de la nature de l'activité. Mais n'en choisir aucun, c'est-à-dire ne même pas avoir remarqué la situation, est l'option la plus coûteuse : votre notice de protection des données donne alors aussi une information inexacte, et une seule lacune finit par enfreindre deux obligations à la fois.
La réglementation en la matière continue d'évoluer, et les décisions du Conseil redessinent le cadre de temps à autre. Il convient de vérifier la situation actuelle avant de choisir un mécanisme de transfert.

## 72 heures en cas de violation de données : où passe le temps côté logiciel

Source : https://kulular.com.tr/fr/publications/notification-violation-donnees

La notification d’une violation est présentée comme une procédure juridique. Mais la part de ce délai qui sera perdue dépend de la façon dont le système a été conçu, des mois avant l’incident.
Une alerte arrive sur le bureau d'une organisation un lundi matin : un accès inhabituel a été détecté sur un serveur. À partir de cet instant, le compte à rebours des soixante-douze heures commence.
Soixante-douze heures, cela paraît long. Ce qui suit est un récit heure par heure de l'endroit où ce temps part réellement, car sans voir cette répartition, il est difficile de comprendre pourquoi la préparation face à une violation doit se faire des mois à l'avance, pas pendant qu'elle se produit.
Les huit premières heures : s'agit-il vraiment d'une violation ?
La première tâche consiste à déterminer si l'alerte est réelle. Il peut s'agir d'un faux positif, d'une opération de maintenance ou d'une autorisation mal configurée.
À ce stade, l'équipe technique examine les journaux. Si les journaux ne sont pas assez bons, et dans la plupart des organisations ils ne le sont pas, cela s'éternise. Sans savoir quel compte a accédé à quelle table depuis quelle adresse, aucune étape suivante n'est possible.
Le premier point critique se situe ici. Qui ne tient pas de journaux voit l'horloge s'épuiser à cet endroit précis, et ce temps ne se rattrape jamais.
Les vingt-quatre heures suivantes : quelles données ont été touchées
Une fois établi qu'il s'agit d'une violation, une seule question se pose. Quelles données personnelles se trouvaient sur ce serveur ?
Une organisation dotée d'un inventaire à jour y répond en dix minutes. Une organisation qui n'en a pas essaie de le découvrir en examinant le schéma de la base de données, en vérifiant les noms des tables, en extrayant des enregistrements d'échantillon, en interrogeant les développeurs. Cela seul peut facilement prendre une journée entière.
La seconde moitié de la question est plus difficile. Que contiennent les sauvegardes ? Existe-t-il une copie exportée pour un rapport ? Un échantillon a-t-il été chargé dans un environnement de test ? Si les réponses ne sont écrites nulle part, on finit par se fier à des suppositions, et une notification fondée sur des suppositions doit ensuite être corrigée.
Les douze heures suivantes : combien de personnes sont concernées
Une fois le périmètre délimité, il faut produire un chiffre. Combien de personnes concernées, quelles catégories de données, quelles zones géographiques.
Une erreur fréquente ici consiste à arrondir le chiffre. Dire « environ dix mille personnes » n'entraînera pas le rejet de la notification, mais si un chiffre réel très différent apparaît par la suite, cela nuit à la crédibilité de ce que l'organisation a déclaré. S'il est impossible d'obtenir un chiffre précis, mieux vaut le dire ainsi, et en expliquer la raison, que d'en avancer un au hasard.
Le temps restant : préparer et envoyer la notification
La notification au Conseil doit couvrir quand et comment la violation s'est produite, quelles catégories de données ont été touchées, ses conséquences possibles ainsi que les mesures prises et prévues.
Rédiger cela à partir d'une page blanche consomme le temps restant. Une organisation disposant déjà d'un modèle le remplit en une demi-heure. Qui est habilité à la signer doit également être décidé à l'avance, car si cette discussion commence à ce stade, il n'y a plus de temps pour elle.
Notifier les personnes concernées est une tâche distincte. Elle se fait dès que raisonnablement possible une fois les personnes concernées identifiées ; si un contact direct n'est pas possible, un autre moyen approprié est utilisé. Le langage compte ici. Un message noyé dans le détail technique empêche la personne de comprendre ce qu'elle doit réellement faire.
Ce que le plan doit vraiment contenir
La leçon de ce parcours est la suivante. La valeur d'un plan de réponse aux incidents réside dans le fait d'avoir réfléchi à l'avance à ce qu'il faudrait réfléchir au moment de l'incident.
Il faut une répartition claire des rôles. Qui délimite l'incident, qui décide qu'il s'agit d'une violation, qui signe. Un plan qui dépend d'une seule personne s'effondre le jour où cette personne est absente.
Il faut un seuil défini. Ce qui constitue une violation doit être écrit à l'avance, sinon cette discussion se déroule dans les soixante-douze heures.
Il faut une règle de préservation des preuves. Le premier réflexe est souvent de nettoyer les systèmes touchés, ce qui rend impossible une enquête adéquate. Le plan doit indiquer explicitement que les journaux sont conservés intacts.
Il faut des modèles de communication déjà préparés, tant pour le Conseil que pour les personnes concernées.
Rien ne se termine à l'envoi de la notification
La notification n'est pas la fin de l'obligation. Le Conseil évalue si les mesures techniques et organisationnelles prises étaient suffisantes.
Une violation qui se répète dans la même organisation est interprétée comme la preuve que ces mesures n'étaient pas suffisantes. C'est pourquoi l'action corrective adoptée après une violation doit être consignée et son effet mesuré. La phrase « les mesures nécessaires ont été prises » ne constitue en soi la preuve de rien.
La seule chose qui vaille la peine d'être faite aujourd'hui
Ce qu'il y a de plus rentable à faire avant de subir une violation, c'est d'établir l'inventaire avec l'emplacement physique des données : quelle base de données, quelle table, quel champ et quelle sauvegarde contient chaque donnée.
Si ce tableau existe, environ les trente premières des soixante-douze heures sont de fait récupérées. S'il n'existe pas, aussi bien rédigé que soit le plan, le temps ne suffira pas.

## Pourquoi la notice d’information doit correspondre au schéma de la base de données

Source : https://kulular.com.tr/fr/publications/rediger-notice-information

Cet article commence par un texte juridique, mais la source du problème est dans le logiciel. L’endroit qui montre le plus fidèlement quelles données une organisation collecte, c’est le schéma de la base de données de l’application qu’elle utilise. Si la notice d’information ne correspond pas à ce schéma, la correction doit le plus souvent commencer par le système, pas par le texte.
Quand j'examine la notice de protection des données d'une organisation, je ne commence pas par la lire. Je commence par prendre les catégories de données qu'elle énumère et par les comparer au schéma de la base de données.
Cette comparaison donne presque toujours le même résultat : des champs existent que la notice ne mentionne pas. Parfois c'est l'inverse, des catégories figurent dans la notice mais ne sont jamais collectées par le système. Les deux cas révèlent le même problème de fond. La notice a été tirée d'un modèle, non d'une vérification réelle des faits.
L'obligation n'est pas de produire un document
L'article 10 de la loi n° 6698 exige que le responsable du traitement, lors de la collecte de données personnelles, communique certains éléments : son identité, la finalité du traitement, les destinataires auxquels les données seront transférées et pourquoi, la méthode de collecte et le fondement juridique, ainsi que les droits énoncés à l'article 11.
Le verbe clé ici est communiquer. Le document est un véhicule, l'obligation consiste à donner une information exacte. Une notice qui donne une information inexacte est pire que l'absence de notice, car l'organisation a alors formulé une déclaration qui ne correspond pas à la réalité.
C'est pourquoi la rédaction de la notice doit venir après l'inventaire, pas avant. Une organisation qui dispose d'un inventaire rédige sa notice en une journée. Celle qui n'en a pas la rédige sans vraiment savoir de quoi elle parle.
Les cinq erreurs que je rencontre le plus souvent
Je constate les mêmes erreurs depuis des années, et aucune ne provient d'un manque de connaissances juridiques.
Fusionner la notice et le consentement explicite dans une seule case à cocher. L'utilisateur coche "j'ai lu et j'accepte" et est réputé à la fois informé et consentant. Une notice est une communication, pas quelque chose que l'on accepte. Cette fusion fragilise le caractère de déclaration de volonté distincte propre au consentement.
Présenter la notice après que l'opération est déjà terminée. Le formulaire est envoyé, puis un lien vers la notice apparaît sur une page de remerciement. À ce stade, les données ont déjà été collectées.
Forcer une seule notice à couvrir tous les processus. Recrutement, contact client, relations fournisseurs et visites du site sont regroupés dans un seul document. Le résultat est une notice générale qui ne décrit fidèlement aucun d'entre eux.
Ne pas indiquer le fondement juridique, ou les énumérer tous à la fois. Une formule telle que "dans le cadre des conditions prévues aux articles 5 et 6" n'indique aucun fondement juridique. Il faut indiquer celui dont dépend réellement le traitement concerné.
Ne pas indiquer la durée de conservation. Le communiqué exige que cette information figure dans les renseignements donnés à la personne concernée, et sans elle, celle-ci n'a aucun moyen de savoir combien de temps ses données seront conservées.
Comment la notice doit être structurée
Une bonne notice se rédige processus par processus. Elle ne commence pas par "notre société traite vos données personnelles", elle commence par "lorsque vous remplissez le formulaire de contact, les données suivantes sont traitées".
Établir un tableau à quatre colonnes pour chaque processus facilite grandement la tâche : catégorie de données, finalité du traitement, fondement juridique, durée de conservation. Ce tableau une fois prêt, la notice s'écrit pratiquement d'elle-même, et le lecteur peut réellement y trouver ce qu'il cherche.
La langue compte aussi. Le communiqué exige que l'information soit transmise de façon claire, compréhensible et simple. Dans la pratique, on observe l'inverse. Les notices s'allongent, les phrases s'alourdissent, et le résultat devient illisible. Une notice que personne ne lit ne remplit pas sa fonction de communication. La simplifier n'est pas ici un choix de style, c'est ce qu'exige l'obligation.
Tenir la notice à jour
Une notice de protection des données n'est pas un document que l'on rédige une fois pour toutes. Lorsqu'un nouveau champ est ajouté, qu'un nouveau prestataire entre en jeu ou qu'un nouveau transfert est mis en place, la notice doit elle aussi être mise à jour.
La seule façon durable d'y parvenir est de lier la mise à jour au processus de développement lui-même. Une modification qui ajoute un nouveau champ de données personnelles au modèle de données doit déclencher la mise à jour à la fois de l'inventaire et de la notice. Sans ce lien, la notice s'éloigne de la réalité dès la première année, sans que personne ne s'en aperçoive.
C'est ainsi que nous avons établi ce lien sur notre propre site. Lorsque nous avons ajouté la fonction d'analyse assistée par intelligence artificielle, une section distincte expliquant le transfert international est entrée en même temps dans la notice. La fonction n'a pas été mise en ligne sans elle. C'est l'ordre qu'il faut respecter.

## Logiciel conforme à la KVKK : commencer par l’inventaire des données

Source : https://kulular.com.tr/fr/publications/conformite-kvkk

Les organisations viennent souvent nous voir en disant qu’elles veulent un logiciel conforme à la KVKK. Pour voir où cette conformité commence dans le code, il faut d’abord regarder l’inventaire, car sans savoir quelles données sont conservées et où, on ne peut définir correctement ni les règles d’accès ni les durées de conservation.
Lorsqu'on intervient dans une organisation pour une mise en conformité KVKK, on trouve généralement ceci. Une notice d'information, un formulaire de consentement exprès, une politique de conservation et de destruction. Les trois sont préparés, signés, classés.
On pose alors une seule question. D'où viennent les catégories de données mentionnées dans ces textes ?
La réponse est le plus souvent celle-ci. Un modèle trouvé sur internet a été repris, le nom de l'organisation y a été inscrit, quelques points ont été ajoutés. Autrement dit, la déclaration ne découle pas d'une vérification des faits, mais d'un modèle type. C'est l'erreur d'ordre la plus fréquente et la plus coûteuse que je constate dans les démarches de mise en conformité.
Pourquoi l'ordre compte autant
La notice d'information est une déclaration. L'article 10 de la loi exige que le responsable du traitement communique les catégories de données traitées, les finalités, les destinataires auxquels les données seront transférées et la base juridique. Si vous faites une déclaration, celle-ci doit être exacte.
Un texte rédigé sans inventaire ne peut pas être exact. Au mieux, il sera incomplet. Lorsqu'un audit détecte une activité de traitement absente du texte, il ne s'agit pas d'une simple lacune technique, mais du non-respect de l'obligation d'information de manière adéquate.
L'inverse est également vrai. Une organisation disposant déjà de l'inventaire rédige sa notice d'information en une journée, car tout ce qu'il y a à écrire est déjà établi.
Ce que l'on recherche réellement dans l'inventaire
Le tableau d'inventaire est généralement établi avec les colonnes catégorie de données, finalité et durée de conservation. Ces trois colonnes ne suffisent pas.
La colonne manquante est celle-ci. Où cette donnée se trouve-t-elle physiquement ? Dans quelle base de données, quelle table, quel champ ? Existe-t-elle aussi dans les sauvegardes ? Une copie existe-t-elle dans le système d'un prestataire tiers ?
Quand cette question n'est pas posée, l'inventaire reflète l'opinion que l'organisation a d'elle-même, et non la réalité. Lorsqu'une violation de données survient, la première question sera « quelles données personnelles se trouvaient sur ce serveur ». Un inventaire qui n'indique pas l'emplacement physique est inutile à ce moment-là.
Le choix de la base juridique est une décision architecturale
L'article 5 de la loi énumère les conditions de traitement. En pratique, cet article est souvent considéré comme une formalité, alors que la base juridique choisie détermine directement la manière dont le système doit être construit.
Dans une activité de traitement fondée sur le consentement exprès, celui-ci peut être retiré à tout moment. Dès son retrait, le traitement doit cesser. Cela impose trois choses au système. Un enregistrement indiquant à quelle version du texte le consentement a été donné, une interface offrant à l'utilisateur la possibilité de le retirer, et un contrôle qui arrête le traitement correspondant lorsque le consentement est retiré. Si l'un de ces trois éléments manque, s'appuyer sur le consentement place l'organisation dans une position indéfendable.
À l'inverse, un traitement nécessaire à l'exécution d'un contrat ne requiert pas ces mécanismes. La même donnée, traitée sur une base juridique différente, génère une charge technique complètement différente. C'est pourquoi le choix de la base juridique ne doit pas être fait par l'avocat seul, indépendamment de l'architecture.
La durée de conservation et le composant qui l'applique
Fixer une durée de conservation est la partie la plus facile du travail de mise en conformité. En assurer l'application est la partie la plus difficile.
Une conception qui fonctionne se présente ainsi. Chaque enregistrement porte sa propre durée de conservation, par exemple un champ « fin_conservation ». Un traitement automatisé parcourt régulièrement les enregistrements dont le délai a expiré. Ce traitement supprime, détruit ou anonymise l'enregistrement et consigne l'opération effectuée dans une table distincte. Ce qui est présenté lors d'un audit n'est pas le texte de la politique, mais cette table.
Les organisations qui ne mettent pas en place cette structure font généralement ceci. Elles inscrivent le délai dans la politique, reportent l'application à une date ultérieure, et cette date n'arrive jamais. Deux ans plus tard, on se retrouve avec des données non supprimées et un document indiquant qu'elles auraient dû l'être. La coexistence de ces deux éléments est pire que de n'avoir écrit aucune politique.
VERBİS et la question du périmètre
L'obligation d'inscription au Registre des responsables du traitement est soumise à des critères fixés par le Conseil. Le nombre annuel de salariés, la taille du bilan financier et la nature des données traitées sont déterminants.
Un avertissement s'impose ici. Le périmètre de l'exemption a évolué dans le temps par des décisions du Conseil et peut continuer à évoluer. Une organisation exemptée aujourd'hui devient assujettie lorsque son effectif augmente. C'est pourquoi l'exemption n'est pas une question à trancher une fois pour toutes et à oublier, elle doit être vérifiée chaque année. Pour les seuils actuels, il convient de consulter les communiqués publiés par l'Autorité.
Le plan de violation se rédige à l'avance
Le cinquième alinéa de l'article 12 de la loi exige que la violation soit notifiée au Conseil aussi rapidement que possible. Les décisions du Conseil ont concrétisé ce délai à soixante-douze heures.
Soixante-douze heures, c'est le temps total alloué, après détection de l'incident, pour déterminer son périmètre, identifier les personnes concernées et préparer la notification. Même la première de ces étapes prend des jours dans la plupart des organisations, car l'emplacement de chaque donnée n'est écrit nulle part.
Autrement dit, la préparation face à une violation commence bien avant celle-ci, et ramène toujours au même point. L'inventaire.
Que se passe-t-il quand la mise en conformité est terminée
Elle ne se termine pas. Une nouvelle fonctionnalité engendre un nouveau champ de données. Un nouveau prestataire engendre un nouveau transfert. Les décisions du Conseil resserrent le cadre.
C'est pourquoi il faut cesser de concevoir la conformité comme un projet et l'intégrer au sein même du processus de développement du produit. Si la mise à jour de l'inventaire lors de l'ajout d'un nouveau champ devient partie intégrante de la revue de code, le processus se maintient de lui-même. Sinon, on repart de zéro chaque année, et la même erreur d'ordre se répète à chaque fois.

## Un logiciel LegalTech doit faire plus que produire des documents

Source : https://kulular.com.tr/fr/publications/technologies-juridiques

Les technologies juridiques sont l’un des cinq domaines dans lesquels nous développons des logiciels. L’erreur la plus fréquente que nous voyons ici est de chercher la valeur du produit dans le document qu’il produit. La vraie valeur, c’est que la règle s’applique à chaque fois de la même façon dans le système.
En examinant la présentation d'un produit de technologie juridique, vous verrez très probablement ceci. Il génère des projets de contrats, propose des clauses, met en forme le document. Ce sont des tâches utiles. Le problème est que la véritable question du domaine n'est pas là, et que le problème que ces outils sont censés résoudre n'est en réalité que la partie la plus facile du problème.
La véritable question se situe ici. Une organisation est soumise à une obligation juridique. Une interprétation est faite sur ce que signifie cette obligation. L'interprétation est consignée dans un document. Ce document est ensuite classé, et le fonctionnement quotidien de l'organisation se poursuit sans tenir compte de ce document. Cette rupture entre le document et le système est l'erreur la plus coûteuse que je constate en pratique, et aucun outil de modèles de contrats ne la résout.
Interpréter relève de l'humain, appliquer relève du système
Transformer une règle en logiciel ne consiste pas à écrire la règle dans le code. Entre les deux se trouve une étape qui ne peut être automatisée.
L'article 7 de la loi n° 6698 dispose que, lorsque disparaissent les motifs qui rendaient nécessaire son traitement, la donnée personnelle est effacée, détruite ou anonymisée. Cette disposition est claire. Mais que signifie exactement « la disparition du motif » s'agissant des données de facturation d'une organisation ? La fin de la relation client, l'expiration du délai de conservation prévu par la législation fiscale, ou la plus tardive des deux échéances ? C'est à un juriste de répondre à cette question. Sa réponse constitue une interprétation, et tant que cette interprétation n'est pas consignée, personne ne se souviendra, six mois plus tard, pourquoi ce délai précis a été choisi.
C'est là que commence le travail du logiciel. Une fois l'interprétation arrêtée, veiller à ce qu'elle soit appliquée de la même manière à chaque fois et que cette application puisse être démontrée. Si vous disposez d'un système qui accomplit cela, vous utilisez une technologie juridique. Si vous vous contentez de générer des modèles, vous utilisez un traitement de texte.
Ce qui se passe lorsque document et système se dissocient
Prenons un exemple concret. La politique de conservation d'une organisation indique que les enregistrements de communication avec les clients seront conservés pendant deux ans. Lorsqu'un audit survient, cette politique est présentée.
L'auditeur pose une seule question. Quel composant applique ce délai ?
La réponse, le plus souvent, n'existe pas. La base de données comporte un champ created_at, mais pas de champ expires_at. Il n'existe aucun traitement qui supprime l'enregistrement à l'échéance du délai. Même si une suppression a lieu, elle ne produit aucune trace. Au final, l'organisation ne peut pas démontrer qu'elle fait ce que sa politique indique. La politique elle-même n'est pas une preuve, tout au plus une déclaration d'intention.
La façon de corriger ce tableau n'est pas de rédiger un meilleur texte de politique. C'est d'ajouter au modèle de données un champ portant le délai de conservation, d'écrire un composant qui applique ce délai, et de faire en sorte que ce composant produise une trace lorsqu'il s'exécute. Lorsque ces trois éléments sont réunis, le texte de la politique cesse d'être une simple affirmation pour devenir la description de ce que le système fait réellement.
Les cinq maillons de la chaîne
La transformation d'un texte juridique en un contrôle qui fonctionne dans le système se fait en cinq étapes. L'ordre de ces étapes compte, et l'omission de l'une d'elles rend le résultat non fiable.
On identifie d'abord la disposition. On détermine la règle applicable et, le cas échéant, son exception. Puis on procède à l'interprétation, c'est-à-dire que l'on décide de ce que la règle signifie dans le processus métier concret. Cette étape relève de l'humain et doit être consignée. À la troisième étape, l'interprétation est rattachée à l'architecture, en déterminant quel champ portera quelle règle. À la quatrième étape, on rédige le composant qui applique la règle au moment de l'opération. À la cinquième étape, l'exécution de ce composant est enregistrée.
Un contrôle rédigé sans interprétation préalable applique la mauvaise règle. Un contrôle qui ne produit pas de preuve ne sert à rien lors d'un audit. L'erreur que je rencontre fréquemment consiste à sauter les troisième et quatrième étapes pour passer directement à la cinquième. L'organisation tient un journal, y consigne des éléments, mais on ne sait pas quelle règle ce journal démontre avoir été appliquée.
La question du monopole de l'avocat
Il existe une limite que toute personne développant des produits dans ce domaine doit connaître. L'article 35 de la loi sur la profession d'avocat n° 1136 réserve aux avocats le suivi des affaires juridiques et la délivrance de consultations juridiques.
En pratique, cela détermine ce que votre produit peut et ne peut pas dire. Dire « il manque cette clause dans votre contrat » relève de l'information. Dire « ne signez pas ce contrat, cela se retournera contre vous » relève de la consultation. La frontière entre les deux est ténue et doit être délibérément préservée dans la conception du produit. La méthode la plus solide pour préserver cette frontière consiste à ce que le système ne prenne pas lui-même la décision et qu'une décision humaine reste visible derrière chaque résultat.
Cette limite ressemble à un obstacle, mais elle constitue en réalité une bonne contrainte de conception. Un système qui n'assume pas la décision n'assume pas non plus la responsabilité lorsqu'il commet une erreur, ce qui empêche l'utilisateur de faire aveuglément confiance au système.
Ce que l'intelligence artificielle a changé, et ce qu'elle n'a pas changé
Le traitement du langage naturel apporte un véritable gain d'efficacité dans l'examen des documents. Retrouver un type de clause précis parmi des centaines de contrats était autrefois un travail de plusieurs semaines. Cela prend désormais quelques heures.
Ce qui ne change pas, c'est la responsabilité. Si l'on ne peut pas retracer de quel document et de quel paragraphe provient le résultat produit par le modèle, ce résultat n'est pas une constatation, c'est une supposition. De même, si le système ne distingue pas visiblement un résultat dont il n'est pas sûr d'un résultat dont il est sûr, l'utilisateur leur accorde à tous une confiance égale, et l'erreur passe inaperçue.
Lorsque ces deux conditions ne sont pas réunies, le gain d'efficacité obtenu est ensuite compensé par le risque qui en découle. Et le pire, c'est que l'on ne sait pas quand ce risque se matérialisera.
Par où commencer
Au lancement d'un projet d'entreprise en technologie juridique, je recommande de choisir une seule obligation. Les aborder toutes en même temps semble séduisant, mais en pratique, aucune n'aboutit.
Pour l'obligation choisie, les cinq maillons sont construits dans leur intégralité. La disposition est rédigée, l'interprétation est consignée, rattachée au modèle de données, le contrôle fonctionne, la preuve est produite. Ce travail se termine en six semaines, et à la fin, vous ne disposerez pas d'un rapport, mais d'un contrôle opérationnel et d'un enregistrement présentable lors d'un audit.
La deuxième obligation avance beaucoup plus vite. Car la difficulté ne réside pas dans la règle, mais dans le fait de construire la chaîne pour la première fois.

## La responsabilité de l’État dans les start-up des technologies spatiales

Source : https://kulular.com.tr/fr/publications/droit-spatial

Pour les équipes qui traitent des données satellitaires ou développent des logiciels pour des start-up du spatial, cette règle paraît lointaine. Elle influence pourtant de nombreuses décisions, de la façon de conserver les données à la structure des contrats.
En droit spatial, il existe une seule règle qui fonctionne différemment de toutes les autres branches du droit, et la plupart des entrepreneurs ne l'apprennent que trop tard.
L'article 6 du Traité de l'espace de 1967 dispose que les États sont internationalement responsables des activités spatiales nationales. Le résultat ne change pas même lorsque l'activité est menée par une entreprise privée. L'article ajoute en outre que ces activités sont soumises à l'autorisation et à la surveillance continue de l'État concerné.
Un exemple permet de mieux saisir ce que cela signifie. Lorsqu'une entreprise de logiciels commet une erreur, elle en répond devant son client. Lorsqu'une entreprise spatiale commet une erreur, c'est l'État qui devient responsable envers un autre État. La différence n'est pas une différence d'échelle, c'est une différence de nature.
Comment se construit la chaîne de responsabilité
La Convention sur la responsabilité de 1972 concrétise cette chaîne. Pour les dommages causés à la surface de la Terre ou à un aéronef en vol, l'État de lancement porte une responsabilité sans faute. Autrement dit, la faute n'est pas exigée.
Cela produit une conséquence directe sur le plan commercial. L'État voudra reporter sur l'opérateur privé cette responsabilité susceptible de peser sur lui. C'est pourquoi le document d'autorisation comporte généralement des clauses de recours, une obligation d'assurance et des exigences de garantie. Si, au début de la négociation du contrat, vous ne connaissez pas le montant de ces postes, vous ne connaissez pas non plus le coût réel du projet.
L'immatriculation y est liée. La Convention sur l'immatriculation de 1975 prévoit l'inscription des objets lancés dans l'espace. L'immatriculation détermine sous la juridiction et le contrôle de quel État se trouve un objet. C'est donc là que commence la réponse à la question de savoir quel droit s'applique.
La carte des autorisations en Turquie
L'Agence spatiale turque a été créée en 2018 par décret présidentiel et est chargée d'élaborer le programme spatial national et de coordonner les activités.
Mais l'activité spatiale ne se limite pas à un seul organisme. L'utilisation des fréquences et des orbites est soumise à un régime distinct, dans lequel les réglementations de l'Union internationale des télécommunications sont déterminantes. Au niveau national, l'autorité compétente est l'organisme turc des technologies de l'information et des communications. Si le contrôle des exportations est en jeu, d'autres autorités interviennent également.
Au lancement d'un projet, il faut établir cette carte. Quelle autorisation, auprès de quel organisme, dans quel ordre et en combien de temps. Ce calendrier avance indépendamment du calendrier de développement technique et est généralement plus long que lui. Ce qui retarde le projet n'est souvent pas le logiciel, mais l'autorisation.
Les données elles-mêmes sont une question à part
Le problème pratique que je rencontre le plus souvent dans les projets spatiaux n'est pas technique, il concerne les données.
Les droits sur les données de mission doivent être régis par les contrats de lancement et d'exploitation. S'il subsiste une lacune dans le contrat, la résoudre par la suite est très difficile, car la partie adverse a alors déjà eu accès à ces données, et une limitation rétroactive ne fonctionne pas en pratique.
Les données d'observation de la Terre soulèvent une question à part. À mesure que la résolution augmente, la probabilité que la donnée acquière un caractère personnel se renforce. Une image sur laquelle la plaque d'immatriculation d'un véhicule est lisible n'est pas soumise au même régime qu'une image à l'échelle d'une ville. Lors de la conception du système, il faut déterminer à partir de quelle résolution un régime de traitement différent s'applique, et cela doit être établi comme un point de contrôle au sein même de la chaîne de données.
Le troisième point est l'intégrité. L'origine de la donnée de télémesure, son horodatage et son absence de modification doivent pouvoir être démontrés. C'est la seule chose qui aura valeur probante lors d'un examen mené après un incident. S'il existe une possibilité que l'enregistrement ait été produit a posteriori, l'enregistrement lui-même ne sert à rien pour la défense.
Le débat sur l'extraction de ressources
L'article 2 du Traité interdit l'appropriation nationale. La situation de l'extraction de ressources sur les corps célestes au regard de cette interdiction n'est pas claire.
Certains États ont adopté, dans leur législation interne, des dispositions reconnaissant la propriété sur la ressource extraite. La compatibilité de ces dispositions avec le Traité est discutée, et aucune pratique internationale établie ne s'est encore formée sur ce sujet. Ce que l'on peut dire honnêtement à une entreprise travaillant dans ce domaine est ceci. Le terrain juridique n'est pas stabilisé, et cette incertitude doit être inscrite comme un poste de risque dans la décision d'investissement. Toute opinion présentée comme certaine donne, à ce jour, une information incomplète.
Ce qu'il faut apporter à la table des négociations
Dans les projets spatiaux, je constate le même problème partout où l'équipe technique et l'équipe juridique travaillent séparément. Les décisions prises lors de l'écriture du logiciel du segment sol influencent directement le régime de responsabilité, et ce lien n'est généralement remarqué qu'après la signature du contrat.
Il faut arriver à la première négociation avec ces trois points déjà clarifiés. Auprès de quel organisme et à quelles conditions l'autorisation sera obtenue. Comment la responsabilité et la charge d'assurance seront réparties entre les parties. À qui appartiendront les droits sur les données de mission et qui pourra y accéder. Une planification technique effectuée sans avoir résolu ces trois points doit ensuite être refaite.

## Quand un logiciel de santé devient-il un dispositif médical ?

Source : https://kulular.com.tr/fr/publications/droit-de-la-sante

Pour une équipe qui développe un logiciel de santé, la réponse à cette question change la durée et le coût du projet. Le même code peut porter une charge de conformité très différente selon la façon dont le produit est défini.
Imaginez deux applications. Toutes deux recueillent les symptômes saisis par l'utilisateur, exécutent un algorithme et renvoient une liste. Le code est presque identique. L'une relève de la réglementation relative aux dispositifs médicaux, l'autre non.
Ce qui fait la différence, c'est le texte descriptif dans la boutique d'applications. La première dit « informe sur les affections possibles selon vos symptômes ». La seconde dit « évalue vos symptômes et affiche le diagnostic probable ». Cette seconde phrase fait de ce produit un produit présenté à des fins de diagnostic, et cela déclenche la classification du risque, l'évaluation de la conformité, le dossier technique, l'évaluation clinique et les obligations de surveillance après mise sur le marché.
C'est l'erreur la plus coûteuse et la plus facilement évitable que je constate dans les projets de technologie de santé. La description du produit est rédigée par l'équipe marketing, personne ne réfléchit à sa conséquence juridique, et le produit se retrouve soumis à un régime de conformité qu'il n'avait jamais été prévu d'assumer.
La finalité d'usage est un texte juridique
La règle pratique qui en découle est la suivante. La description du produit doit être rédigée avec le même soin qu'une politique de confidentialité et faire l'objet d'un examen juridique avant sa publication.
Cet examen ne doit pas se limiter à la description de la boutique. Le titre sur le site web, la phrase dans la vidéo promotionnelle, l'affirmation dans la présentation commerciale et la formulation dans le document d'assistance peuvent produire le même résultat. Si vous avez écrit quelque part « pose un diagnostic », écrire ailleurs « à titre informatif uniquement » ne retire pas cette déclaration.
La décision doit être prise dès le départ. Si le produit doit être un dispositif médical, le processus exigé par ce régime est mis en place dès le début et intégré au plan comme un poste de coût. S'il ne doit pas l'être, le respect de cette limite dans chaque texte doit devenir une règle de développement du produit.
L'architecture d'accès aux données de santé
L'article 6 de la loi n° 6698 classe les données de santé parmi les catégories particulières de données personnelles et soumet leur traitement à des conditions plus restrictives. La traduction technique de cette qualification reste incomplète dans la plupart des projets.
Le tableau que je constate souvent est le suivant. L'application fonctionne, les données sont conservées, mais dans le système, tout le monde peut tout voir. Le développeur peut consulter la base de données de production, l'équipe d'assistance peut ouvrir le dossier du patient, la personne dirigeante peut voir des données brutes dans les rapports. Cela signifie que l'accès n'est pas limité, ce qui est difficile à défendre lors d'un audit.
La bonne conception commence par un contrôle d'accès fondé sur les rôles, mais ne s'arrête pas là. Chaque accès doit être consigné, cette trace doit indiquer qui l'a effectué et dans quel but, et un accès inhabituel doit pouvoir être repéré. Si quelqu'un ouvre le dossier d'un patient en pleine nuit, cela doit être visible dans le système.
L'environnement de test constitue une question à part. Tester avec de véritables données de patients est l'habitude la plus répandue et la plus risquée en technologie de santé. Travailler avec des données masquées ou synthétiques élimine en grande partie ce risque et n'est pas techniquement difficile à mettre en œuvre.
Aide à la décision clinique et responsabilité
Les systèmes d'aide à la décision assistés par l'intelligence artificielle soulèvent la question de savoir qui est responsable. En pratique, la configuration sûre consiste à ce que le système produise une recommandation et que la décision finale soit laissée au professionnel de santé compétent.
Pour que cette configuration ne reste pas seulement sur le papier, trois éléments doivent être conservés ensemble. La recommandation produite par le système, les données sur lesquelles cette recommandation repose, et la décision finale prise par le professionnel de santé. Si ces trois éléments sont conservés séparément, ils ne pourront plus être recoupés par la suite ; s'ils ne sont pas conservés du tout, il devient impossible de démontrer où se situe la responsabilité.
Il est utile d'y ajouter un indicateur. Il faut suivre la fréquence à laquelle le professionnel de santé rejette la recommandation du système. Si ce taux s'approche de zéro, la supervision humaine est devenue formelle, et à ce stade c'est en réalité le système qui prend la décision lui-même. Ce constat peut être déterminant dans un débat sur la responsabilité.
Les services de santé à distance
Les services de santé à distance sont régis par la réglementation du ministère de la Santé. Les services pouvant être fournis à distance, les obligations d'enregistrement et les limites du service sont fixés par la réglementation secondaire. Cette réglementation pouvant évoluer dans le temps, il faut, lors de la conception du produit, se référer au texte en vigueur.
Le principe qui ne change pas est le suivant. Les situations exigeant un examen en personne ne peuvent pas être prises en charge à distance. Une application de santé à distance doit pouvoir reconnaître une demande dépassant cette limite et la réorienter. Que le système puisse dire « pour cette situation, veuillez consulter un médecin » n'est pas une fonctionnalité d'ergonomie, mais une exigence juridique.
Au lancement d'un projet
Dans les projets de technologie de santé, la question à laquelle il faut répondre lors de la première réunion n'est pas ce que le produit va faire, mais ce qu'il va déclarer être. Chaque ligne de code écrite avant que cette question ait reçu une réponse peut avoir été écrite selon le mauvais régime.
La deuxième question concerne le modèle de données. Quelle donnée est réellement nécessaire, qui pourra la voir, où l'accès sera-t-il consigné et que se passera-t-il une fois la finalité atteinte. La réponse à ces quatre questions détermine directement la conception des tables, et la modifier ultérieurement, en exigeant la migration de données de patients déjà existantes, engendre un problème à la fois technique et juridique.

## Logiciel d’examen à distance : caméra obligatoire et proportionnalité

Source : https://kulular.com.tr/fr/publications/droit-education

Pour une équipe qui développe un logiciel d’examen à distance, cette question ressemble à un choix technique. Faut-il activer la caméra, faut-il enregistrer. En réalité, c’est une décision de conception qui détermine quelles données le produit traitera, et elle coûte cher à changer après coup.
Un étudiant refuse d'activer sa caméra lors d'un examen à distance et explique qu'il ne veut pas que son domicile soit filmé. L'établissement répond qu'il faut garantir l'intégrité de l'examen. À ce stade, deux intérêts légitimes s'opposent, et la question n'est pas de savoir lequel des deux a raison, mais si la méthode choisie par l'établissement est réellement nécessaire.
Cette question se pose constamment dans les projets de technologie éducative, et elle est généralement débattue dans un cadre erroné. Le débat se transforme en dilemme « caméra activée ou non », alors que la question qu'il faut juridiquement poser est plus étroite. Le même but peut-il être atteint en traitant moins de données ?
Ce que la proportionnalité interroge
L'article 4 de la loi n° 6698 exige que les données personnelles soient pertinentes, limitées et proportionnées au regard des finalités pour lesquelles elles sont traitées. Ce principe n'est pas un vœu abstrait, c'est un outil de filtrage concret.
L'intégrité de l'examen est un but légitime, cela ne fait aucun doute. Mais ce but ne légitime pas toute donnée pouvant être collectée sur le candidat. Enregistrement vidéo continu, capture d'écran, suivi des mouvements du clavier et de la souris, installation d'un client exigeant des autorisations étendues sur l'appareil. Chacun de ces éléments doit être évalué séparément, et pour chacun il faut se demander : l'intégrité de l'examen ne peut-elle pas être garantie sans cela ?
Dans la plupart des cas, elle le peut. La randomisation de la banque de questions, une limite de temps, le mélange de l'ordre des questions, un poids accru accordé aux questions ouvertes et une analyse statistique des anomalies effectuée a posteriori permettent d'atteindre un niveau sérieux d'intégrité sans enregistrement. Passer directement à l'enregistrement par caméra sans avoir essayé au préalable ces outils est un choix difficile à défendre au regard de la proportionnalité.
Pourquoi le consentement ne fonctionne pas ici
Le premier réflexe des établissements consiste à recueillir le consentement de l'étudiant. Avant le début de l'examen apparaît une case à cocher, et l'étudiant ne peut pas passer l'examen sans l'accepter.
Le problème de ce montage est le suivant. Pour être valable, un consentement doit avoir été donné librement. Il est difficile de soutenir que le consentement d'un étudiant qui, sans l'accepter, ne peut pas se présenter à l'examen, repose sur une volonté libre. De plus, de l'autre côté se trouve l'établissement qui attribue la note, enregistre l'assiduité et influence la décision d'obtention du diplôme. Ce déséquilibre de pouvoir vicie le consentement dès le départ.
La conséquence pratique qui en découle est la suivante. S'appuyer sur le consentement pour les données des élèves donne à l'établissement un sentiment de sécurité, mais n'offre pas de protection juridique. Ce que l'établissement doit faire, c'est évaluer si le traitement repose sur une autre base juridique et, si ce n'est pas le cas, renoncer à ce traitement.
Lorsqu'un enfant est concerné
Pour les élèves en âge de scolarité obligatoire, la situation est encore plus délicate. La capacité à consentir, le rôle des parents et l'intérêt supérieur de l'enfant sont ici des questions qui doivent être évaluées séparément.
Lors de la conception d'une plateforme éducative, des parcours différents doivent être mis en place selon l'âge de l'utilisateur. Proposer la même interface à un élève de dix ans et à un étudiant de master de vingt-cinq ans pose problème non seulement en termes d'ergonomie, mais aussi sur le plan juridique. Un champ du modèle de données portant la tranche d'âge, associé à des règles de traitement différentes, constitue la traduction technique de cette distinction.
Ce que prouve l'enregistrement d'apprentissage
L'aspect le moins discuté de la technologie éducative est l'usage que l'on fait, par la suite, de l'enregistrement produit.
Lorsqu'un étudiant conteste une note, que possède l'établissement entre les mains ? Un simple enregistrement « examen terminé », comme la clôture d'un ticket, ou bien une chaîne montrant à quelle question quelle réponse a été donnée, selon quel critère elle a été notée et qui l'a évaluée ?
Si cette seconde option existe, la contestation se règle en dix minutes. Sinon, la contestation se transforme en une défense qui demande de faire confiance au propre enregistrement de l'établissement, et cette défense est faible. C'est pourquoi, lors de la conception d'un système d'évaluation, l'ordre suivant doit être respecté. On rédige d'abord le résultat d'apprentissage. Le critère de réussite est ensuite rattaché à ce résultat. La question est produite selon le critère. Le registre d'évaluation est conservé. La voie de contestation et la procédure d'examen sont définies à l'avance.
Une fois cette chaîne établie, le certificat de réussite dispose d'un fondement présentable en arrière-plan. Sans elle, le certificat se réduit à une déclaration reposant sur la bonne foi de l'établissement.
Ma recommandation aux établissements
Avant d'acheter un logiciel de surveillance, mesurez dans quelle proportion le problème d'intégrité peut être résolu par la conception même de l'examen. Dans la plupart des établissements, cette mesure n'est jamais effectuée, et l'on passe directement à la solution la plus intrusive.
Si, après cette mesure, la surveillance reste nécessaire, rédigez une justification distincte pour chaque donnée collectée. « Le système la collecte » n'est pas une justification. L'élément dont la justification ne peut être rédigée doit être retiré du système. Cela doit également faire l'objet du contrat conclu avec le fournisseur, car la plupart des produits prêts à l'emploi collectent plus que nécessaire et sont livrés avec de tels réglages par défaut.

## Pourquoi un produit logiciel n’est pas soumis à une seule loi

Source : https://kulular.com.tr/fr/publications/droit-du-numerique

En tant qu’équipe de développement, c’est surtout au début des projets que nous rencontrons cette question. L’organisation demande à quelles règles le logiciel doit se conformer, et la réponse ne tient pas dans une seule loi. Prendre en compte cette dispersion dès la conception coûte bien moins cher que de corriger après coup.
La question « que dit le droit du numérique à ce sujet » n'a pas de réponse, car il n'existe pas de texte unique appelé droit du numérique. C'est la première chose qu'apprend quiconque travaille dans ce domaine, et la plus difficile à expliquer à un client.
En Turquie, les activités numériques sont régies à l'intersection d'au moins six lois distinctes. Aucune d'entre elles n'englobe les autres. Toutes fonctionnent selon leur propre logique, leur propre régime de sanctions et leur propre autorité de contrôle. Le résultat est le suivant. Il n'est pas possible d'établir une liste d'obligations en se référant à un seul texte, et un même fait peut produire des conséquences simultanées sous plusieurs régimes à la fois.
Une violation de données se présente à vous en trois endroits distincts
Il convient de l'illustrer par un exemple concret. Supposons qu'un accès non autorisé ait été obtenu à la base de données clients d'une entreprise de commerce électronique et que les données aient été exfiltrées.
La première voie est administrative. L'article 12 de la loi n° 6698 régit les obligations de sécurité des données, et le cinquième alinéa de ce même article exige que la violation soit notifiée au Conseil. Le Conseil évalue le caractère suffisant des mesures techniques et administratives prises et, s'il les juge insuffisantes, inflige une amende administrative.
La deuxième voie est pénale. Le fait commis par la personne ayant obtenu l'accès peut constituer le délit d'intrusion dans un système informatique au sens de l'article 243 de la loi n° 5237, et l'exfiltration des données peut constituer le délit de transmission ou d'obtention illicite de données au sens de l'article 136. Cette enquête se déroule indépendamment de la responsabilité administrative de l'entreprise.
La troisième voie relève du droit privé. La personne dont les données ont fuité peut demander réparation du préjudice subi. Le dernier alinéa de l'article 11 de la loi réserve expressément ce droit.
Ces trois voies ne sont pas alternatives les unes aux autres, elles fonctionnent simultanément. Avoir payé l'amende du Conseil ne met pas fin à l'enquête pénale, et l'issue du procès pénal ne tranche pas d'elle-même la demande d'indemnisation.
À quelle question répond chaque loi
La façon la plus pratique de comprendre la dispersion de ce domaine consiste à voir à quelle question répond chaque texte.
La loi n° 6698 répond à la question « pouvez-vous traiter cette donnée ? ». Les conditions de traitement, l'obligation d'information, les mesures de sécurité et les droits de la personne concernée s'y trouvent.
La loi n° 5651 répond à la question « qui est responsable de ce contenu ? ». Cette loi régit la distinction entre fournisseur de contenu, hébergeur, fournisseur d'accès et fournisseur d'usage collectif, ainsi que les procédures de retrait de contenu et de blocage de l'accès. Le régime de responsabilité change entièrement selon laquelle de ces quatre qualités s'applique à la personne.
La loi n° 5237 répond à la question « ce fait constitue-t-il une infraction ? ».
La loi n° 6563 répond à la question « pouvez-vous envoyer cette communication commerciale et que devez-vous déclarer en tant que prestataire de services ? ».
La loi n° 5070 répond à la question « cette signature électronique remplace-t-elle la signature manuscrite ? ».
Dans un projet, toutes ces questions se posent généralement en même temps. Une décision prise en ne tenant compte que de l'une d'elles crée un aveuglement à l'égard des quatre autres.
Compétence éclatée signifie contrôle éclaté
Ce qui complique encore ce tableau, c'est que différentes lois sont confiées à des organismes différents.
L'Autorité de protection des données personnelles surveille les activités de traitement des données. L'organisme turc des technologies de l'information et des communications est compétent dans le domaine des communications électroniques et participe à la mise en œuvre des décisions de blocage de l'accès. Le ministère du Commerce est responsable de l'application de la réglementation relative au commerce électronique.
La conséquence pratique en est la suivante. Pour un même produit, vous pouvez être responsable devant plusieurs autorités de contrôle, et ces autorités ne sont pas liées par la décision les unes des autres. Un avis favorable de l'une n'empêche pas l'autre de parvenir à une conclusion différente.
Où l'erreur se produit en pratique
La grande majorité des erreurs que je constate dans ce domaine partagent un trait commun. L'évaluation juridique intervient après que les décisions techniques ont déjà été prises.
Le modèle de données est déjà construit, les tables sont déjà créées, les intégrations sont déjà écrites. Alors que le produit est sur le point d'être mis en production, on dit au juriste « pourriez-vous y jeter un œil ». À ce stade, ce qui peut être dit est limité, car tout ce qui est dit implique désormais une correction rétroactive, et cette correction rétroactive pose un problème distinct au regard des données déjà collectées.
Or, toutes les questions suivantes sont des questions qui auraient pu être résolues lors de la construction du modèle de données. Quelles catégories de données personnelles seront traitées. Sur quelle base juridique reposera chaque catégorie. Quelle sera la durée de conservation et quel composant l'appliquera. Quelles tables seront concernées lorsqu'une demande de suppression arrivera. Y aura-t-il un transfert de données à l'étranger.
Cinq questions. Toutes peuvent trouver réponse en une seule réunion. Le coût qui apparaît lorsqu'elles restent sans réponse dépasse de plusieurs fois le coût de cette réunion.
La véritable difficulté du domaine
La difficulté du droit du numérique ne réside pas dans la complexité des règles. Les règles, lues une à une, sont compréhensibles.
La difficulté consiste à savoir à quel moment chaque règle entre en jeu. La décision d'un ingénieur de « conservons aussi ce champ, ça pourrait servir » produit des conséquences au titre de trois lois distinctes, et la personne qui prend cette décision l'ignore la plupart du temps. Combler ce déficit de connaissance ne passe pas par un dossier de conformité plus épais, mais par la présence du juriste à la table où la décision est prise.