Développer avec l'IA : vous héritez de la conformité de l'éditeur

Starbucks dépense environ 400 millions de dollars par an en logiciels, selon son directeur technique. Le 9 juillet 2026, la chaîne a annoncé qu'elle allait remplacer deux outils métier qu'elle achetait jusqu'ici — Microsoft Dynamics 365 pour l'inventaire, IBM Tririga pour la maintenance — par du logiciel développé en interne avec l'IA. Le marché a réagi tout de suite : IBM a chuté de 3 à 5 % en pré-marché, Microsoft d'environ 1 %. Deux titres du Dow Jones qui bougent parce qu'une chaîne de cafés a décidé de coder elle-même ce qu'elle achetait avant.

Ce n'est pas une anecdote de grande entreprise qui ne vous concerne pas. C'est le même mouvement que vous faites, vous, solopreneur, quand vous demandez à un assistant IA de vous générer un CRM interne, un outil de facturation, un connecteur entre deux services, une petite app pour votre équipe — que ce soit en écrivant du code avec un assistant type Claude ou Cursor, ou en assemblant un workflow sans code sur une plateforme d'automatisation. Starbucks le fait à l'échelle de 400 millions de dollars. Vous le faites à l'échelle d'un week-end. Le mécanisme est identique : ce qu'on appelle parfois le « vibe coding » — décrire ce qu'on veut et laisser l'IA produire — déplace la frontière de qui fabrique le logiciel, mais pas celle de qui répond de ce qu'il fait.

La réaction du marché n'est pas un détail. Si IBM et Microsoft perdent de la valeur en pré-marché sur l'annonce d'un seul client qui internalise deux outils, c'est que les investisseurs prennent au sérieux l'idée que le logiciel maison assisté par IA n'est plus un bricolage de développeur isolé, mais une alternative crédible à l'achat de SaaS établis. Ce qui vaut pour un groupe coté vaut, structurellement, pour n'importe quel solopreneur qui fait le même arbitrage à sa mesure.

Ce que l'éditeur faisait pour vous, sans que vous le voyiez

Quand vous achetiez un SaaS — un outil de gestion de stock, une plateforme de tickets, un CRM — vous ne payiez pas seulement pour des fonctionnalités. Vous payiez aussi, sans le formuler ainsi, pour que quelqu'un d'autre porte une part de la charge de conformité à votre place. L'éditeur tenait son propre registre des traitements. Il documentait ses sous-traitants et ses transferts de données. Il patchait ses dépendances quand une faille sortait. Il signait avec vous un contrat de sous-traitance — le DPA de l'article 28 du RGPD — qui posait noir sur blanc qui fait quoi avec vos données. Vous n'aviez presque jamais besoin d'y penser : vous héritiez du travail de quelqu'un d'autre, en silence, inclus dans l'abonnement.

C'est exactement ce que Starbucks arrête de faire avec Dynamics 365 et Tririga. Et c'est exactement ce que fait un solopreneur qui remplace un SaaS payant par un outil généré en une soirée avec Claude, Cursor ou Copilot. Dans les deux cas, le raisonnement affiché est le même : pourquoi payer pour un logiciel générique quand on peut en produire un sur mesure, plus vite, moins cher, avec l'IA ?

Le raisonnement est bon. Ce n'est pas l'objet de cet article de le contester — construire vite avec l'IA est une force, pas une faute. Mais il a une conséquence que personne n'énonce à voix haute : le jour où vous fabriquez vous-même ce que vous achetiez, vous héritez aussi de tout ce que l'éditeur portait pour vous. L'IA vous a donné le pouvoir de produire un logiciel en quelques heures. Elle ne vous a transmis aucune des obligations qui allaient avec ce logiciel quand quelqu'un d'autre le vendait.

L'angle mort de gouvernance

Ce trou n'est pas théorique, il est structurel. Un outil que vous générez avec l'IA n'a par défaut ni registre, ni documentation de ses appels externes, ni base légale identifiée pour les données qu'il manipule, ni personne qui a vérifié ses dépendances. Rien de tout cela n'est de la mauvaise volonté de votre part : c'est simplement que la question ne se pose jamais au moment où vous écrivez le prompt. Vous demandez « fais-moi un outil qui fait X », l'IA vous livre un outil qui fait X, et le sujet s'arrête là — parce que rien dans l'échange n'a soulevé la question de ce que cet outil fait avec les données qu'il traite.

C'est un angle mort, pas une négligence. Personne ne vous prévient parce que personne n'est en position de le faire : ni l'IA, dont le rôle est de produire du code qui fonctionne, ni vous, qui n'avez souvent jamais eu à vous poser ces questions puisque vous achetiez avant. Le mécanisme est le même que pour n'importe quel outil qu'on adopte sans lire la doc jusqu'au bout — sauf que là, il n'y a pas de doc du tout, puisque c'est vous l'éditeur.

Ce que vous devez désormais faire vous-même

Voici, concrètement, ce que portait l'éditeur et que vous portez maintenant.

Le registre des traitements, d'abord — l'article 30 du RGPD. Quelles données votre outil manipule, pour quelle finalité, combien de temps elles sont conservées, où elles résident physiquement. Un éditeur SaCloud avait ce registre prêt à vous montrer en cas de question. Le vôtre, sur l'outil que vous venez de générer, n'existe probablement pas encore.

La documentation des sous-traitants, ensuite. Votre code fraîchement généré appelle une API de LLM pour enrichir une fiche client, résumer un email, classer un ticket ? C'est un transfert de données vers un tiers. Vers quel pays ? Sous quel régime juridique ? Avec quelle garantie sur ce que ce tiers fait de la donnée qu'il reçoit ? Un éditeur documentait cette chaîne. Un outil généré en une soirée ne la documente jamais spontanément — il fonctionne, et c'est tout ce qu'on lui a demandé.

La base légale de chaque traitement déclenché par votre code — consentement, exécution d'un contrat, intérêt légitime — est un exercice que personne ne fait automatiquement en écrivant un prompt. La sécurité, aussi : les dépendances de votre projet, les secrets qui traînent dans le code, le chiffrement des données stockées, tout ce qu'un éditeur patchait en continu parce que c'était son métier devient désormais le vôtre, silencieusement, sans que vous ayez signé quoi que ce soit qui vous le rappelle.

La transparence prévue par l'article 50 de l'AI Act s'ajoute si vous mettez votre outil en service auprès de tiers — vous en devenez alors fournisseur, et ses § 1 (informer qu'on parle à une IA, sauf si évident) et § 2 (marquage lisible par machine des contenus synthétiques) vous visent. Si vous vous contentez d'utiliser une IA pour développer, sans exposer de système à autrui, l'article ne vous concerne pas. Et enfin, la preuve — pas la certification, la preuve de diligence. Montrer que vous y avez pensé, et à quel moment vous y avez pensé. C'est le cœur de ce que le RGPD attend réellement de vous : une obligation de moyens, pas un résultat parfait.

Ce raisonnement ne s'arrête pas au code écrit ligne par ligne. Un workflow assemblé sans code sur une plateforme d'automatisation, un agent bâti dans un outil no-code qui enchaîne plusieurs services, produit exactement le même angle mort : personne n'a rédigé de registre pour ce que le workflow fait circuler entre ses briques, parce que la plateforme vous a laissé assembler des blocs, pas réfléchir aux flux de données qu'ils créent une fois connectés entre eux.

Le code généré n'est pas moins bon, il est moins relu

Un point mérite d'être dit sans moralisme, parce qu'il traîne une confusion fréquente. Le code produit par l'IA n'est pas d'une qualité inférieure au code écrit à la main — les études comme les usages quotidiens le confirment largement. Le problème n'est pas la qualité du code, c'est l'attention qu'on lui porte après coup. Personne ne relit 800 lignes générées en dix minutes avec la même rigueur que 80 lignes tapées à la main sur deux heures. Ce n'est pas un défaut de l'IA, c'est un fait d'attention humaine : plus la production va vite, moins la relecture suit le rythme. Et la conformité — les flux de données, les appels externes, les dépendances embarquées — se cache précisément dans ce qui n'est pas relu.

C'est ce même mécanisme qui joue chez Starbucks à l'échelle de centaines de millions de dollars, et chez vous à l'échelle d'un outil de facturation fait en un après-midi. Produire vite et bien n'a jamais été le problème. Le problème, c'est que la vitesse de production a distancé la vitesse de relecture, et que personne ne le remarque avant qu'un client, un partenaire ou une autorité pose la question.

Ce que vous pouvez faire aujourd'hui, gratuitement

Vous n'avez besoin de rien pour commencer. Ouvrez le dernier outil que vous avez généré avec l'IA — celui qui tourne déjà, celui que personne n'a encore audité parce qu'il marche. Cherchez, dans le code, tous les endroits où une donnée part vers l'extérieur : un appel API, un webhook, un import de librairie qui téléphone chez son éditeur. Notez-les. Puis écrivez trois lignes : quelle donnée, vers qui, pourquoi. C'est le début d'un registre, et il vous prend vingt minutes.

Ce que ce travail manuel ne vous donne pas, en revanche, c'est la garantie de n'avoir rien oublié dans les milliers de lignes que vous n'avez pas écrites vous-même. C'est précisément ce que fait POSITRONIA-CORE : le scan tourne sur votre machine, votre code ne part jamais nulle part, et vous obtenez un regard automatique sur ce que vous avez produit — sans avoir à envoyer une ligne de ce code à un tiers pour le faire vérifier. Il ne vous met pas en conformité ; il vous dit où regarder, et vous laisse une trace que vous pourrez montrer le jour où quelqu'un — un client, un DPO, un avocat — vous demandera si vous y avez pensé.