Les mains et la machine
Mon grand-père faisait (AUSSI) du travail du bois. Quand on lui demandait comment il savait si un morceau de bois était bon, il ne sortait pas de théories. Il s’arrêtait, le faisait tourner dans ses mains, le sentait, et puis disait : « tu le sens ».
Chaque fois que je repense à cette scène, ça me fait sourire, puis une étrange nostalgie me prend. Parce que je fais du logiciel depuis vingt ans et que, lorsqu’un client me demande comment je sais si un système est bon, j’aimerais pouvoir répondre pareil. J’aimerais pouvoir dire « tu le sens » et m’arrêter là.
Sauf que la vérité est plus compliquée, et c’est peut-être justement le point.
Le logiciel ne se touche pas. Ne se sent pas. Ne se regarde pas à contre-jour pour chercher les veines. Et pourtant il est partout. C’est la chose la plus puissante et la plus invisible que nous ayons construite.
Et quand une chose est aussi invisible, la confiance devient tout.
Le monde tourne sur des choses que vous ne voyez pas
Ce matin, vous avez pris le petit-déjeuner. Le lait que vous avez acheté est arrivé au supermarché en traversant une chaîne logistique gouvernée par du logiciel. Le paiement à la caisse est passé par plus de systèmes qu’on n’imagine, souvent sans que personne ne le remarque.
Le feu rouge que vous avez croisé en sortant de chez vous exécute un algorithme. L’ascenseur a un firmware. Votre salaire est un nombre dans une base de données.
Je ne dis pas ça pour faire de l’effet. C’est juste le monde tel qu’il est aujourd’hui.
Et arrive ici le paradoxe qui m’inquiète un peu. Presque personne, parmi ceux qui décident comment fonctionne la société, n’a une compréhension profonde de ces systèmes. Pas par bêtise ou paresse. Plutôt par un défaut structurel de notre culture : pendant des années, on a traité la technologie comme une chose de techniciens, un département, un coin de la carte.
Pendant ce temps, elle est devenue le tissu conjonctif de tout.
Quand un conseil d’administration approuve un système basé sur de l’IA pour filtrer les candidatures, prend-il une décision technologique ? Oui. Mais il prend aussi une décision éthique, juridique, sociale. Il décide quels biais sont acceptables, quelle marge d’erreur est tolérable, combien d’opacité est admissible dans un processus qui change la vie des gens.
Et souvent, il ne le sait pas.
Ce qui arrive quand personne ne comprend la machine
Il y a une histoire qu’on connaît bien dans notre métier, mais qu’on raconte rarement hors de nos pièces.
Dans presque tous les systèmes que vous utilisez, du site de la banque à l’app de livraison de repas, il y a de petits morceaux de code écrits par des personnes que vous ne rencontrerez jamais. Ce sont des bibliothèques open source : des composants gratuits, partagés, souvent maintenus par un seul individu sur son temps libre.
Il y a quelque temps, quelqu’un a tenté d’insérer une porte dérobée dans l’une de ces bibliothèques, un composant utilisé par des millions de serveurs dans le monde. La tentative a été découverte presque par hasard : un ingénieur s’est aperçu que le système mettait une demi-seconde de plus à démarrer. Une demi-seconde.
De cette demi-seconde, on a remonté à une opération sophistiquée, probablement parrainée par un État, qui aurait pu compromettre des infrastructures critiques à l’échelle mondiale.
Ce qui devrait nous empêcher de dormir, ce n’est pas que quelqu’un ait essayé. C’est que toute la chaîne de sécurité dépendait d’une seule personne, un bénévole, qui maintenait ce code sur son temps libre tout en luttant contre le burnout.
Ce n’est pas une anecdote isolée. C’est un modèle. Et je me demande souvent jusqu’où il peut tenir.
L’IA n’est pas intelligente (et c’est très bien)
Soyons clairs ici, parce que le marketing a fait un travail incroyable pour brouiller les pistes.
Les systèmes que nous appelons « intelligence artificielle » ne pensent pas. Ne comprennent pas. N’ont ni intentions, ni désirs, ni objectifs propres. Ce sont des machines statistiques d’une puissance sans précédent, capables de trouver des motifs dans des quantités de données qu’aucun humain ne pourrait traiter, et de produire des résultats qui semblent intelligents.
Cette distinction n’est pas académique. Elle est pratique. C’est l’une de ces choses qui changent la façon dont vous prenez des décisions.
Si vous croyez que l’IA comprend, vous finirez par la traiter comme une experte. Vous ferez confiance à son jugement. Vous lui déléguerez des choix. Et quand elle se trompera — parce qu’elle se trompe, parfois de manière subtile —, vous n’aurez pas les outils pour vous en rendre compte.
Si en revanche vous la voyez pour ce qu’elle est, un outil très puissant, alors tout retrouve une perspective plus saine. Un outil se guide, se vérifie, se sécurise. Un bistouri est extraordinaire dans la main d’un chirurgien, et il est dangereux dans n’importe quelle autre. La différence n’est pas dans le bistouri.
Pour qui écrit du logiciel, cette conscience change le travail. Peut-être qu’on n’écrit plus chaque ligne soi-même, ou en tout cas pas de la même façon. Mais on doit comprendre chaque ligne, parce que c’est nous qui répondons de ce que le système fait.
La machine génère. L’humain garantit.
Et cette garantie a un poids qu’aucun modèle statistique ne peut endosser.
L’Europe fait quelque chose de courageux (et presque personne ne le voit)
Pendant que les big tech américaines et chinoises courent, l’Europe fait autre chose. Elle écrit des règles.
Je sais, la réaction instinctive est le bâillement. Règles, bureaucratie, lenteur, énième frein à l’innovation.
Mais arrêtez-vous un instant. C’est peut-être, et je dis bien peut-être, l’un des rares mouvements vraiment politiques que l’on voit en ce moment.
L’Europe est en train de dire que la technologie n’est pas au-dessus de la loi. Que si tu produis un logiciel qui prend des décisions sur les personnes, tu dois pouvoir expliquer comment il fonctionne. Que si ton produit numérique a une vulnérabilité, tu en es responsable, comme un constructeur automobile l’est d’un défaut de freins.
AI Act, Cyber Resilience Act, Product Liability Directive, European Accessibility Act. Des noms arides, oui. Mais derrière, une intuition très concrète : au XXIe siècle, réguler la technologie, c’est réguler la société.
Pour qui fait de l’entreprise, cela signifie coûts et complexité, ce serait naïf de le nier. Mais cela signifie aussi autre chose, qui me semble sous-évaluée : un avantage concurrentiel potentiel énorme.
Quand le marché mondial se réveillera en demandant des produits numériques sûrs, transparents, accessibles, ceux qui auront déjà bâti ces qualités dans leur manière de travailler seront en tête.
La compliance peut être un poids, c’est vrai. Mais elle peut aussi être un investissement, si tu l’intègres au processus et ne la traites pas comme une feuille à signer à la fin.
Un SBOM compilé par obligation, c’est un fichier dans un dossier. Un SBOM compilé en conscience, c’est une carte de ton produit, un outil de gouvernance, presque une déclaration de maturité.
Open source : le don le plus grand et le plus fragile de l’ère numérique
Il y a quelque chose de profondément beau dans l’open source. Quelqu’un écrit un morceau de code, le publie, et dit au monde : prends-le, utilise-le, améliore-le.
C’est de la générosité, mais pas au sens romantique. C’est la construction d’un bien commun.
Et sur ce bien commun repose l’économie numérique mondiale. Ce n’est pas une exagération. Si ce logiciel devait être réécrit de zéro, la valeur estimée serait de l’ordre de milliers de milliards. Mais celui qui le maintient ne reçoit qu’une fraction infime de cette valeur.
Le problème est systémique. Les grandes plateformes construisent des services à milliards sur des bibliothèques maintenues par des bénévoles épuisés. Les gouvernements utilisent de l’open source dans des infrastructures critiques sans contribuer vraiment à la maintenance. Les entreprises intègrent des composants ouverts dans leurs produits propriétaires sans savoir ce qu’il y a dedans, jusqu’à ce qu’une vulnérabilité les force à le découvrir de la pire manière.
Cory Doctorow parle d’enshittification, ce cycle où les plateformes extraient de la valeur jusqu’à dégrader l’écosystème. L’open source n’est pourtant pas une plateforme. Il ressemble plutôt à un jardin.
Et un jardin, si tout le monde cueille et personne n’arrose, meurt.
La bonne nouvelle, c’est que quelque chose bouge. L’Europe, avec le CRA, commence à distinguer celui qui maintient du code par passion et celui qui le commercialise. Certaines entreprises créent des fonds dédiés. Mais la réponse la plus efficace reste la plus simple, et aussi la plus inconfortable.
Si tu utilises de l’open source dans ton produit, contribue. En code, en fonds, en reconnaissance. Pas parce que tu dois. Parce que c’est intelligent, et parce que c’est juste.
Accessibilité : le test ultime de nos intentions
Il existe un moyen quasi infaillible de savoir si une entreprise prend ses valeurs au sérieux. Ne regardez pas la page « qui sommes-nous ». Regardez si son site fonctionne avec un lecteur d’écran.
L’accessibilité, c’est ce point où la rhétorique rencontre la réalité. Tu peux parler d’inclusion et de diversité tant que tu veux, mais si ton produit numérique n’est pas utilisable par une personne ayant un handicap visuel, moteur ou cognitif, ces mots deviennent vides.
Et puis, disons-le, on ne parle pas d’une niche.
En Europe, des dizaines de millions de personnes vivent avec une forme de handicap. À ceux-là s’ajoutent les personnes âgées, celles avec un handicap temporaire, quiconque se trouve dans un contexte défavorable : le soleil sur l’écran, une connexion lente, un appareil ancien.
L’accessibilité n’est pas une faveur. C’est une mesure de la qualité de notre travail. Un logiciel accessible est presque toujours un meilleur logiciel : plus propre dans le code, plus clair dans l’interface, plus robuste.
L’European Accessibility Act rendra beaucoup de choses obligatoires à partir de 2025. Mais ceux qui attendent la loi pour faire ce qui est juste, à mon avis, ont déjà raté le point.
Aux développeurs : vous n’êtes pas en danger, vous êtes en transformation
Ici je m’adresse à celles et ceux qui font le même métier que moi. À celles et ceux qui vivent entre commits et déploiements, entre bugs et refactorings.
Je sais qu’il y a de la peur. Je la vois dans les conversations, dans les messages, parfois dans les blagues. La question est toujours la même, même quand elle n’est pas dite : « dans cinq ans, est-ce qu’on aura encore besoin de moi ? »
Je respire.
On est passés des feuilles de calcul aux bases de données relationnelles. Des sites statiques aux frameworks. Du déploiement manuel au CI/CD. Et maintenant du code écrit à la main au code assisté par IA. Chaque fois, le sol a tremblé. Chaque fois, ceux qui ont su s’adapter ont découvert que le nouveau sol était plus fertile que l’ancien.
La valeur n’a jamais été dans la frappe. Elle était dans la compréhension. Dans la capacité à regarder un problème et à voir la structure sous la surface. À parler avec un utilisateur et traduire des frustrations en un système qui marche. À choisir quand construire et quand réutiliser. À savoir qu’un test n’est pas de la bureaucratie, c’est de l’amour pour le futur.
Ces compétences ne sont pas automatisables. Elles sont amplifiables.
La machine qui écrit du code est un multiplicateur de tes capacités, mais seulement si tu en as à multiplier. Un IDE avec IA dans les mains de qui comprend ce qu’il fait est un outil extraordinaire. Dans les mains de qui ne comprend pas, c’est un générateur de dette technique à grande vitesse.
Étudiez, oui, mais pas seulement les nouveaux outils, parce qu’ils changeront. Étudiez les fondamentaux : architecture, design de systèmes, principes de sécurité, accessibilité. Étudiez les gens : comment ils communiquent, ce qu’ils craignent, ce qu’ils espèrent. Et étudiez aussi le contexte normatif, pas parce que c’est amusant, mais parce qu’il définit le terrain de jeu.
Et surtout, n’arrêtez pas d’être curieux. La curiosité est une chose étrange, pas toujours « productive » au sens d’entreprise du terme. Mais c’est l’un des rares avantages compétitifs qu’une machine ne peut pas vraiment répliquer.
Une question de confiance
Au fond, toute cette conversation — sur l’IA, l’open source, la régulation, l’accessibilité — tourne autour d’un seul mot : confiance.
Faisons-nous confiance à des systèmes que nous ne voyons pas ? Devrions-nous ? À quelles conditions ?
La confiance ne se construit pas avec des déclarations d’intention. Elle se construit avec des choix concrets, répétés dans le temps, vérifiables. Elle se construit en documentant les dépendances, en testant le code, en rendant le produit accessible, en expliquant les décisions de l’algorithme, en répondant des erreurs.
Pour les décideurs, la technologie n’est pas un département. C’est la langue dans laquelle est écrite l’organisation. Vous n’avez pas besoin de devenir programmeurs, loin de là. Mais il faut comprendre assez pour poser des questions inconfortables aux fournisseurs, distinguer un risque réel d’une assurance creuse, comprendre ce qu’il y a dans le logiciel qui gouverne les processus.
Pour nous, développeurs, le travail n’a jamais été seulement technique. Chaque choix d’architecture est un choix de valeurs. Chaque donnée que nous décidons de ne pas collecter est un droit que nous choisissons de respecter. Chaque interface que nous rendons accessible est une porte que nous ouvrons.
Le code est du pouvoir, et le pouvoir comporte une responsabilité.
Et donc : le bois et le code
Mon grand-père n’aurait pas compris mon métier. Il aurait probablement secoué la tête devant certains mots, puis changé de sujet.
Mais je crois qu’il en aurait compris le principe.
Lui, il savait qu’un meuble bien fait se reconnaît aux assemblages qu’on ne voit pas. À la stabilité qui dure dans le temps. Au soin mis dans les détails que le client ne remarquera jamais, mais qui font la différence entre un objet qui dure vingt ans et un qui craque au bout de six mois.
Le bon logiciel est pareil. Il se reconnaît à ce qu’on ne voit pas : à la sécurité qui n’est pas violée, à l’accessibilité qui n’exclut personne, à la vie privée qui n’est pas trahie, à la documentation qui permet à celui qui vient après de comprendre ce que tu as fait et pourquoi.
Ce n’est pas un métier que l’IA va nous prendre. C’est un métier que l’IA, d’une certaine manière, est en train de nous rendre dans sa forme la plus pure : non plus comme acte mécanique de traduction, mais comme acte humain de soin.
Et le soin, comme le savait mon grand-père en regardant le bois, tu le sens.
Cet article est pour celles et ceux qui écrivent du code et pour ceux qui en dépendent sans le savoir. Pour celles et ceux qui décident sans comprendre et pour ceux qui comprennent sans pouvoir décider. Peut-être pour nous tous, parce qu’à la fin la réponse est toujours la même : ça dépend de nous.
Ce qu'il faut retenir
Le monde tourne sur des systèmes que presque personne, parmi ceux qui décident, ne comprend vraiment : traiter la technologie comme un département est une erreur de civilisation.
L’IA n’est pas intelligente : c’est une machine statistique très puissante. La machine génère, l’humain garantit.
Les règles européennes ne freinent pas l’innovation, elles construisent l’infrastructure de confiance sans laquelle le reste ne tient pas.
L’open source est un jardin : si tout le monde cueille et personne n’arrose, il meurt.
Chaque choix d’architecture est un choix de valeurs ; chaque donnée non collectée est un droit respecté.
Questions & réponses
Pourquoi la confiance dans le logiciel est-elle différente de la confiance dans un objet matériel ?
Parce que le logiciel est invisible. Le menuisier peut faire tourner un bout de bois dans ses mains, le sentir, le regarder à contre-jour. Celui qui livre un système logiciel n’a aucun de ces outils sensoriels : le client voit un écran, pas la structure réelle du fonctionnement. Quand une chose est aussi opaque, la confiance ne repose plus sur la perception directe et doit se construire avec des mécanismes substitutifs : documentation, audit, garanties, responsabilité légale.
Que veut dire construire la confiance avec soin, quand on fait du logiciel ?
Accepter que la confiance ne se déclare pas, elle se construit par des choix vérifiables : qualité du code, traçabilité des dépendances, transparence sur les décisions prises, reconnaissance des erreurs, gestion responsable des incidents. Ces choses sont invisibles au client quand elles fonctionnent. Ce sont elles que le client achète vraiment, même si dans le contrat il n’est écrit que « développement de plateforme ».
Comment la confiance évolue-t-elle avec l'IA et l'open source dans le tableau ?
Dans deux directions opposées. L’IA accroît l’écart d’opacité : on ne sait plus exactement ce que fait le système, même quand on regarde dedans. L’open source, à l’inverse, offre un outil de vérification inédit — n’importe qui peut lire le code — mais demande de la compétence pour s’en servir. La confiance se déplace de « le producteur dit » à « la communauté peut vérifier ».
Pourquoi les règles européennes parlent-elles de confiance et pas seulement de sécurité ?
Parce que la sécurité est une propriété technique mesurable, la confiance est une propriété sociale. CRA, AI Act et PLD n’imposent pas seulement des mesures de sécurité : ils imposent traçabilité, documentation accessible, responsabilité du producteur — soit l’infrastructure sur laquelle la confiance peut se reconstruire quand le produit est invisible au client. Il ne suffit pas de faire du logiciel sûr, il faut pouvoir le démontrer.
L'auteur
