Catégorie : Éthique et philosophie de l’IA

  • L’AI Act vous demande de former vos équipes mais ne dit pas à quoi.

    L’AI Act vous demande de former vos équipes mais ne dit pas à quoi.

    Le 2 août, l’AI Act est entré dans les réunions de direction par la porte des chatbots et des deepfakes. L’obligation qui concerne directement vos équipes est en vigueur depuis dix-huit mois, et personne n’en parle. Le marché l’a réduite à deux heures de formation et un certificat. En juillet, le législateur a même précisé qu’elle n’exigeait aucun niveau. C’est précisément ce qui la rend intéressante.

    Le 2 août, une nouvelle salve d’obligations de l’AI Act est entrée en application. Vous en avez sûrement entendu parler sous la forme de trois consignes : le chatbot doit dire qu’il est un chatbot, les contenus générés doivent porter un marquage lisible par machine, les deepfakes doivent être étiquetés.

    Trois sujets d’éditeurs et de plateformes. Rien qui concerne la façon dont vos équipes travaillent au quotidien. Pourtant l’obligation qui les concerne existe, elle est en vigueur depuis dix-huit mois, et je n’ai vu personne la commenter cet été. C’est l’article 4.

    Il s’applique à toute entreprise qui déploie un système d’IA, quel que soit son niveau de risque et sans seuil d’effectif. Le cabinet d’expertise comptable de douze personnes dont les collaborateurs révisent des liasses avec un assistant est concerné. La PME industrielle de quatre-vingts personnes dont les techniciens SAV diagnostiquent des pannes avec un copilote l’est aussi.

    Et l’ampleur est connue : selon une enquête YouGov pour Microsoft France menée en janvier auprès de 657 cadres et dirigeants, 80 % des dirigeants utilisent l’IA générative chaque semaine, 61 % des utilisateurs passent par des comptes personnels, et plus de sept cadres sur dix n’ont reçu aucune formation.

    Trois chiffres qui, mis côte à côte, décrivent un usage massif, invisible pour l’entreprise, et sans cadre.

    Que demande le texte ? Depuis sa réécriture par le règlement Omnibus entré en vigueur le 27 juillet 2026, l’article 4 tient en deux phrases.

    « Les fournisseurs et les déployeurs de systèmes d’IA prennent des mesures pour soutenir le développement de la maîtrise de l’IA de leur personnel et des autres personnes chargées du fonctionnement et de l’utilisation de ces systèmes pour leur compte, en tenant compte de leurs connaissances techniques, de leur expérience, de leur éducation et de leur formation, du contexte dans lequel les systèmes seront utilisés, et des personnes ou groupes de personnes à l’égard desquels ils seront utilisés. Cette obligation n’impose pas aux fournisseurs ou aux déployeurs de garantir un niveau particulier de maîtrise de l’IA à quelque individu que ce soit. »

    La version de 2024 parlait d’assurer un niveau suffisant. Celle de 2026 parle de soutenir un développement, et ajoute la dernière phrase. Le législateur a renoncé à fixer le niveau et laisse à chaque entreprise la charge de définir ce qui est proportionné à sa situation. Il ne lui fournit aucun instrument pour le mesurer.

    Le marché, lui, a fixé le niveau. Taper seulement « article 4 AI Act » dans un moteur de recherche pour voir la page se remplir d’offres de formation. Le format est partout le même : une sensibilisation de deux heures, parfois une journée, un quiz, un certificat individuel par participant. Et presque toujours le même avertissement en tête de page : 15 millions d’euros ou 3 % du chiffre d’affaires mondial en cas de manquement. Ce barème existe dans le règlement. Il figure à l’article 99, paragraphe 4, qui énumère les obligations sanctionnées à ce niveau. L’article 4 n’en fait pas partie. Il n’apparaît dans aucune des listes d’infractions de l’article 99.
    Le chiffre qui vend la formation appartient à un paragraphe où l’obligation qu’elle prétend couvrir n’est pas citée…

    La Commission européenne a mis ses réserves par écrit. Sa foire aux questions sur l’article 4 précise que se contenter de la notice d’utilisation du système, ou demander au personnel de la lire, risque d’être inefficace. Elle a publié un répertoire de pratiques rassemblant une quarantaine d’initiatives, plateformes d’e-learning, formations en présentiel, bootcamps. Et elle prévient, en tête du répertoire, que reproduire ces pratiques ne confère aucune présomption de conformité. L’institution qui porte le texte publie un catalogue de formations en précisant qu’il ne prouve rien.

    Pourquoi un certificat ne prouve-t-il rien ? Parce qu’il atteste qu’une formation a eu lieu, pas qu’une compétence est conservée. Or l’usage lui-même érode cette compétence. Des développeurs, des médecins, des analystes suivis pendant des mois font moins bien sans l’outil qu’avant de l’avoir. J’ai détaillé ces études dans un billet précédent. Un seul chiffre pour fixer l’ordre de grandeur : face à un assistant qui se trompe avec assurance, des participants passent de 46 % à 31 % de bonnes réponses. Ils ne corrigent pas la machine, ils lui cèdent.

    Reprenez le technicien SAV de tout à l’heure. Il a suivi sa formation en mars. Depuis, l’assistant lui propose un diagnostic à chaque intervention, et dans neuf cas sur dix il a raison. En novembre, un client appelle depuis un site sans réseau. Le technicien a le certificat dans son dossier RH. A-t-il encore le geste ?

    Il faut maintenant dire ce que l’article 4 n’est pas. Ce n’est pas la seule disposition du règlement qui parle de compétence. C’est la seule en vigueur aujourd’hui, et la seule qui vise tous les systèmes. La version dure existe.

    L’article 14, sur les systèmes à haut risque, exige que la personne chargée du contrôle humain reste consciente de sa tendance à se fier automatiquement aux sorties du système. Le texte emploie le terme de biais d’automatisation. La reddition cognitive de Wharton est écrite dans la loi. Le même article exige que cette personne puisse, dans toute situation, décider de ne pas utiliser le système ou de passer outre son résultat.

    L’article 26 impose aux déployeurs de confier ce contrôle à des personnes qui ont la compétence, la formation et l’autorité nécessaires. Sans phrase de décharge, cette fois. Et là, les 15 millions ou 3 % s’appliquent bel et bien : l’article 26 est nommément listé à l’article 99.
    Sauf que l’Omnibus a repoussé l’entrée en application de ce chapitre au 2 décembre 2027 pour la plupart des systèmes concernés.

    Voilà la situation réelle. Pendant quinze mois, aucune entreprise n’a d’obligation mesurable sur le jugement de ses équipes face à l’IA. L’obligation en vigueur précise qu’elle n’exige aucun niveau. L’obligation exigeante n’est pas encore opposable. Et pendant ce temps l’érosion, elle, court.

    Un détail de plus : l’Omnibus charge le Comité européen de l’IA d’écrire des recommandations et des objectifs communs pour la maîtrise de l’IA. Le référentiel n’existe pas encore. Il s’écrira d’ici 2027, et il s’écrira à partir de ce que les entreprises auront su montrer.

    Reste la question que tout dirigeant se pose : concrètement, que risque-t-on ? Pas d’amende européenne sur l’article 4. Les États membres doivent prévoir des sanctions effectives et proportionnées dans leur droit national, et ce sont les autorités nationales de surveillance du marché qui contrôlent depuis le 2 août, pas la Commission.

    En France, aucune autorité n’est nommément en charge de l’article 4 ; le paysage est réparti entre la CNIL, la DGCCRF, l’Arcom et d’autres selon les secteurs. La Commission précise qu’une sanction est surtout probable lorsqu’un incident survient et que la formation des personnes en cause s’avère insuffisante. Personne ne viendra donc vérifier votre registre un lundi matin. En revanche, le jour où une décision prise avec l’IA tourne mal, un devis erroné envoyé à un grand compte, un diagnostic manqué, une clause oubliée dans un contrat, la question posée ne sera pas « avez-vous une attestation ? ». Elle sera : « vos équipes étaient-elles en mesure de voir que l’outil se trompait ? ».

    Un certificat ne répond pas à cette question. Une mesure y répond. Un certificat mesure une formation suivie. Un savoir-faire se mesure sur ce que les équipes font encore sans l’outil.

    Les trois dimensions que je proposais de suivre dans le billet précédent prennent ici un autre statut. Elles deviennent des preuves, et elles se mettent en place sans laboratoire.

    Les voici en synthèse :

    • L’autonomie résiduelle : une fois par trimestre, dix dossiers déjà traités sont refaits sans l’outil, et on regarde ce qui tient. Si le technicien retrouve neuf diagnostics sur dix, il comprend son système. S’il en retrouve cinq, la formation n’a rien conservé.
    • La qualité du discernement : la part des propositions de l’IA qui ont été modifiées, contestées ou refusées avant validation. Ce chiffre existe déjà dans les journaux d’usage de tous les assistants, personne ne le lit. Une équipe qui accepte 97 % des propositions telles quelles ne connaît pas les limites de son outil, quoi qu’en dise son certificat.
    • La transmission : le temps qu’il faut aujourd’hui à un nouvel arrivant pour atteindre l’autonomie qui était la norme avant l’IA. Si ce délai s’allonge, la formation produit des utilisateurs, pas des professionnels.

    Aucun régulateur n’exige ces trois mesures mais aucun ne pourra les contester.

    Il y a deux manières de lire l’article 4. Le lire comme une contrainte produit du papier, à 200 euros HT la personne. Ou le lire comme une question de savoir-faire.

    La deuxième produit deux choses. Une preuve solide le jour où l’on vous la demande. Et, une information que très peu d’entreprises possèdent aujourd’hui : cas d’usage par cas d’usage, les endroits où l’IA rend vos équipes meilleures et ceux où elle les rend juste plus rapides. Autrement dit, quels savoir-faire vous acceptez de laisser partir parce qu’ils ne font plus la différence, et lesquels vous choisissez de protéger. Le législateur n’a pas écrit ce texte pour cela. Rien n’interdit de s’en servir ainsi.

    C’est exactement le travail que nous faisons à La Forge avec les dirigeants qui nous sollicitent. On part de leurs savoir-faire, pas de leurs outils. On les cartographie avec eux, puis pour chaque cas d’usage de l’IA on tranche une posture : substituer, augmenter, piloter ou entraîner. Cette décision fixe ce qu’on accepte d’automatiser et ce qu’on refuse de voir s’éroder. Ensuite nous suivons ensemble et dans la durée les trois mesures ci-dessus (autonomie, discernement et transmission), au même rang que les données, la conformité et les coûts. Le jour où une autorité, un client ou un assureur pose la question, la réponse est un historique, pas une attestation.

    Si la question se pose chez vous, écrivez moi: trajectoire@la-forge.ai

    Dans la même série :

  • AXIOS, VERTEX, FICOBA : ce que ces trois incidents nous disent sur la sécurité des produits IA

    AXIOS, VERTEX, FICOBA : ce que ces trois incidents nous disent sur la sécurité des produits IA

    Les cyberattaques ne frappent plus seulement les grandes entreprises. Les startups et ETI, avec leurs infrastructures cloud rapides et leurs équipes réduites, sont devenues des cibles de choix. À travers les cas Axios, Vertex et FICOBA, cet article explore le paradoxe des équipes qui innovent sur des fondations fragiles et comment construire autrement.

    83 millions de téléchargements par semaine. C’est le rythme auquel Axios, bibliothèque JavaScript invisible pour le grand public mais cruciale pour des millions d’applications, irriguait l’écosystème numérique mondial. Mardi 1ᵉʳ avril 2026, cette infrastructure silencieuse s’est transformée en cheval de Troie. Deux versions piégées. Un logiciel malveillant capable de s’exécuter sur macOS, Windows et Linux. Une compromission planifiée 18 heures à l’avance, conçue pour effacer ses propres traces après infection. Cette attaque n’est pas anecdotique. Elle est symptomatique d’une réalité que les startups technologiques refusent encore de voir : leurs fondations reposent sur du sable mouvant. Pendant qu’elles gagnent en vélocité grâce aux agents de code IA, leur surface d’attaque explose. Pendant qu’elles déploient en quelques jours ce qui prenait des mois, leur dette sécuritaire s’accumule en silence. La sécurité ne peut plus être traitée comme une contrainte qu’on gère après coup. Elle demande une posture fondamentalement différente intégrée dès la conception, et pensée comme une condition de durabilité du produit.

    I. L’onde de choc : quand l’infrastructure devient arme

    Google Threat Intelligence ne s’embarrasse pas de nuances : « L’impact de cette attaque est vaste et entraîne un effet domino, car d’autres bibliothèques très utilisées s’appuient sur Axios. » La Corée du Nord, via le groupe UNC1069 et son malware WAVESHAPER.V2, ne visait pas une entreprise. Elle ciblait l’écosystème.

    La même semaine, Vertex AI, service d’intelligence artificielle de Google Cloud utilisé massivement par les startups pour leurs modèles ML, révélait qu’une simple mauvaise configuration d’un agent pouvait exposer un environnement cloud entier. Quelques jours plus tard, le fichier FICOBA français, 1,2 million de comptes bancaires, tombait entre des mains malveillantes.

    Nous ne sommes plus dans une ère de failles isolées, mais de contamination systémique.

    II. Le paradoxe des startups : innover sur du verre brisé

    Les startups construisent sur l’open source. Elles utilisent Axios, React, Node.js, des briques maintenues souvent par une poignée de développeurs bénévoles. Cette architecture distribuée crée une dépendance invisible mais totale envers des infrastructures fragiles.

    Le paradoxe est brutal : pour aller vite, impératif de survie dans l’univers startup, elles accumulent une dette sécuritaire massive.

    Selon notre étude menée auprès de startups françaises :

    • 50% n’ont aucun responsable sécurité formellement désigné
    • 62,5% allouent moins de 5% de leur budget IT à la cybersécurité
    • 0% ont un plan de continuité d’activité documenté et testé

    Cette négligence n’est pas un choix mais une contrainte. Les investisseurs financent la croissance, pas la sécurité. Les équipes techniques se concentrent sur le produit, pas sur la résilience. Aujourd’hui, avec GitHub Copilot, Cursor, et autres agents de code, une startup peut déployer en une semaine ce qui prenait trois mois. Mais cette vélocité amplifie le risque : plus de code produit, plus de dépendances, plus de surface d’attaque. Sans gouvernance sécuritaire.

    Ce n’est pas un défaut de bonne volonté. C’est un défaut de méthode.

    III. La fausse promesse du cloud : sécurité par délégation

    94% des entreprises hébergent au moins une partie de leurs données dans le cloud. Depuis 2020, 79% d’entre elles ont subi au moins une violation. La migration vers AWS, Google Cloud ou Azure crée l’illusion de sécurité par proxy. Les startups confondent infrastructure managée et sécurité garantie. L’attaque sur Vertex AI le démontre : même les services les plus avancés deviennent vulnérables dès qu’ils sont mal configurés.

    C’est précisément ici que la question de la souveraineté opérationnelle devient centrale. Maîtriser son contexte technique, c’est savoir ce qui tourne dans son environnement et comprendre les dépendances qu’on accepte

    Chez La Forge, c’est une question qu’on se pose à chaque projet : est-ce que l’équipe cliente comprend ce qu’elle opère ? Un produit IA qu’on ne comprend plus est un produit qu’on ne maîtrise plus.

    IV. Comment un Forgeron aborde la sécurité quand il construit un produit IA

    La cybersécurité entre dans nos réflexions dès le BUILD, et structure une partie du RUN.

    Dans le BUILD, quelques que l’on s’applique :

    • Minimiser les dépendances : on n’intègre pas une bibliothèque parce qu’elle est populaire. On se demande si elle est maintenue, auditée, et si on peut s’en passer.
    • Tracer ce qu’on déploie : chaque brique technique doit être documentée, versionnée, observable. Pas juste pour faire de la conformité, mais pour pouvoir réagir vite si quelque chose change.
    • Considérer les agents IA comme des vecteurs d’attaque potentiels : un agent mal paramétré peut exposer bien plus qu’une API mal configurée. La question du scope de ses permissions est critique dès la conception.

    Dans le RUN, la sécurité devient une question d’observabilité et de gouvernance :

    • Qui a accès à quoi ? Est-ce que les droits accordés en développement ont été révisés avant la mise en production ?
    • Est-ce qu’on surveille les comportements anormaux, ou est-ce qu’on attend qu’un incident nous prévienne ?
    • Est-ce que l’équipe cliente a les moyens de comprendre ce qui tourne dans son environnement, ou est-ce qu’on a créé une dépendance opaque ?

    Dans nos missions Partenaire IA, l’un de nos objectifs est précisément de transférer cette maîtrise, pas seulement le code, mais la compréhension de ce qu’on a construit et pourquoi.

    V. Conclusion

    Axios est tombé en une nuit. Une bibliothèque centrale pour des millions d’applications, compromise via une attaque planifiée, sans que personne dans la chaîne ne soit directement visé.

    Ce n’est pas une raison de paniquer. C’est une raison de construire autrement.

    La sécurité n’est pas incompatible avec la vélocité. Elle demande simplement qu’on l’intègre comme un paramètre de conception, dès le départ , au même titre que la performance ou l’expérience utilisateur (UX). Les équipes qui y arrivent ne font pas moins vite, elles font plus solidement. Et dans un contexte où les agents IA multiplient la capacité de production, cette solidité devient une vraie différenciation. Pas un frein. Une fondation.

    Références

    • ANSSI. (2025). Panorama de la cybermenace 2025.
    • CNIL. (2025). Notifications de violations de données personnelles.
    • Gartner. (2025). Supply Chain Attack Predictions.
    • Google Threat Intelligence. (2026). Axios Compromise Analysis.
    • IBM. (2025). Cost of a Data Breach Report.
    • Verizon. (2025). Data Breach Investigations Report (DBIR).

  • Le vrai danger de l’IA n’est pas qu’elle nous remplace, mais qu’elle nous instrumentalise

    Le vrai danger de l’IA n’est pas qu’elle nous remplace, mais qu’elle nous instrumentalise

    Nous en sommes le carburant. Comment sortir de ce piège ?

    🧠 Kant donne le cadre moral. Nietzsche, le cadre existentiel.

    Kant rappelait que l’être humain est une fin en soi, jamais un simple moyen. Or, les usages actuels de l’IA transforment nos savoir-faire, nos données et nos créations en matière première exploitable. L’humain devient une ressource extractible.

    Ce glissement entraîne deux dérives majeures :
    1️⃣ Instrumentalisation. Nos compétences deviennent du carburant d’entraînement. Le système capte nos idées, notre créativité et organise leur valorisation ailleurs. L’utilisateur perd son rôle d’agent créateur de valeur.

    2️⃣ Inégalité. La méritocratie reposait sur le travail et la compétence. L’IA fait dépendre la valeur de la puissance de calcul, des données et des infrastructures. Le capital technique surpasse l’effort individuel, créant une élite technologique et une masse d’utilisateurs captifs.

    Ces dérives brisent notre contrat social et contredisent l’idée de l’humain comme fin.

    Nietzsche offre ici un contrepoint utile. Il voyait l’homme comme capable de créer ses propres valeurs et de ne pas subir les systèmes qui l’enserrent. Autonomie, responsabilité, affirmation de la vie.

    Dans l’ère numérique, cela signifie cultiver nos qualités distinctives:
    – créativité,
    – empathie,
    – jugement.


    Et les rendre opérantes dans nos usages de l’IA, au lieu de s’en remettre passivement aux systèmes.

    Autrement dit, construire une IA qui augmente l’humain au lieu de l’appauvrir.

    C’est le socle de notre travail à La Forge : concevoir des produits IA performants, durables et responsables.
    Ce qui implique :
    – de rendre leurs utilisateurs meilleurs dans ce qu’ils font,
    – de considérer l’humain comme une finalité (et non un moyen),
    – de renforcer l’autonomie (plutôt que la dépendance).

    Le sens n’est pas donné par la technologie. Il est forgé par celles et ceux qui l’utilisent et la conçoivent.

    Notre responsabilité collective est de structurer l’IA comme multiplicateur humain et non comme extracteur systémique.

    🤔 La question que l’on doit tous se poser maintenant : quelles mesures concrètes pouvons-nous déployer, dans nos organisations et nos sociétés, pour que l’IA soit un multiplicateur humain plutôt qu’un extracteur systémique ?

    sources :

    Initialement publié sur LinkedIn.