Pendant longtemps, créer un système informatique exigeait de savoir, au moins partiellement, comment il fonctionnait.
Il fallait installer un environnement de développement, comprendre quelques notions d’architecture, manipuler une base de données, écrire du code, gérer des droits d’accès, puis déployer le tout. Cette barrière technique était souvent inutilement élevée. Elle réservait la création numérique à une population restreinte et pouvait transformer une modeste application métier en projet de plusieurs mois.
Le low-code et le no-code ont commencé à l’abaisser. L’intelligence artificielle est en train de la faire disparaître.
C’est probablement une excellente nouvelle.
À condition de ne pas confondre la facilité de construire avec la simplicité de ce que l’on construit.
La complexité n’a pas disparu. Nous l’avons masquée.
Un utilisateur métier peut désormais automatiser un processus avec Power Automate, créer une application avec Power Apps ou construire un agent dans Copilot Studio sans maîtriser les technologies sous-jacentes.
Microsoft va aujourd’hui un peu plus loin avec les Skills de Copilot dans SharePoint. Une procédure exprimée en langage naturel peut devenir une compétence réutilisable par Copilot, enregistrée sous la forme d’un simple fichier Markdown. Par défaut, un utilisateur disposant des droits de modification sur le site peut créer une telle compétence et un utilisateur disposant des droits de lecture peut l’utiliser. Les capacités actuelles restent circonscrites à celles de Copilot dans SharePoint.
Pris isolément, rien de tout cela n’est particulièrement inquiétant. C’est même l’aboutissement logique de plusieurs décennies d’évolution informatique : rendre accessibles des technologies qui ne l’étaient pas.
Seulement, pendant que leur interface se simplifie, les systèmes situés derrière elle suivent exactement la trajectoire inverse.
Une entreprise moderne s’appuie sur des services cloud, des dizaines ou des centaines de SaaS, des identités fédérées, des API, des connecteurs, des accès B2B, des plateformes low-code et, désormais, des agents capables de mobiliser plusieurs de ces ressources.
Notre dépendance à cet ensemble est devenue considérable. Une panne informatique peut interrompre la production, empêcher de facturer, bloquer un hôpital ou paralyser une administration.
Nous sommes donc confrontés à une étrange inversion : plus nos systèmes deviennent indispensables et complexes, moins il est nécessaire d’en comprendre le fonctionnement pour agir sur eux.
Nous approchons peut-être d’un point où il devient plus facile de construire un système que de comprendre le système que l’on vient de construire.
Quand des droits légitimes produisent une capacité qui ne l’est plus
Pour rédiger un document ou créer une application de réservation de salles, les conséquences restent limitées.
Mais la même facilité permet progressivement de construire une automatisation capable de lire des données clients, d’interroger un CRM, de mettre à jour Jira et d’agir sur un ERP.
Chacune de ces opérations peut être parfaitement légitime. L’utilisateur possède les droits nécessaires sur chaque système.
Le problème apparaît dans leur composition.
La sécurité informatique s’est historiquement beaucoup préoccupée de savoir qui pouvait accéder à quoi. Elle doit désormais se poser une question supplémentaire : que devient la capacité d’un utilisateur lorsque toutes ses autorisations peuvent être mobilisées, corrélées et exécutées automatiquement par une machine ?
Il n’est même plus nécessaire d’augmenter ses privilèges pour augmenter considérablement son pouvoir d’action.
C’est l’un des changements introduits par les agents : le risque ne réside plus seulement dans l’accès, mais dans ce que la composition d’accès parfaitement légitimes permet désormais d’accomplir.
Du bricolage du mardi au système critique du vendredi
Le low-code a popularisé la notion de « citizen developer ». L’idée est séduisante : permettre aux personnes qui connaissent réellement un processus métier de résoudre elles-mêmes leurs problèmes plutôt que de transformer chaque besoin en projet informatique.
Il serait absurde de renoncer à ce bénéfice.
Mais celui qui assemble quelques composants dans une interface graphique n’a pas nécessairement conscience de créer une application dont dépendra bientôt une équipe entière. Celui qui demande à un agent d’analyser des documents et de mettre à jour plusieurs systèmes ne voit pas davantage les frontières de confiance qu’il vient de créer.
Le petit bricolage du mardi peut devenir le système critique du vendredi.
Ce phénomène existait déjà avec Excel et Access. Ce qui change aujourd’hui est sa vitesse, sa portée et sa faculté de traverser les frontières du système d’information.
Les grands éditeurs le savent parfaitement.
Microsoft documente depuis longtemps les environnements gérés, les politiques de données, la gestion du cycle de vie et les mécanismes destinés à encadrer le développement citoyen.
La démocratisation de la création n’a donc pas supprimé la compétence. Elle a déplacé l’endroit où celle-ci intervient.
La production reste une frontière.
Une frontière que nous savons parfaitement tracer ailleurs
Presque tout le monde utilise quotidiennement une autre infrastructure complexe et potentiellement dangereuse sans en comprendre intimement le fonctionnement : l’électricité.
Sa démocratisation n’a pourtant jamais signifié que chacun pouvait intervenir librement sur l’ensemble de l’installation.
Nous pouvons utiliser une prise électrique. Certaines interventions nécessitent en revanche des professionnels qualifiés. Certaines installations doivent être contrôlées. Le raccordement au réseau répond à des exigences supplémentaires et certaines parties de l’infrastructure restent réservées à son exploitant.
Personne n’en conclut que l’électricité est insuffisamment démocratisée.
Nous avons simplement admis un principe : la liberté d’utiliser une technologie n’emporte pas celle de modifier sans contrôle une infrastructure lorsque les conséquences dépassent son utilisateur.
Curieusement, le numérique a longtemps échappé à cette logique.
Acheter ne dispense pas davantage de comprendre
Certaines organisations ont choisi une réponse apparemment simple au problème : ne construisons plus. Le low-code est restreint, le développement interne découragé et le « buy before build » devient parfois une doctrine.
Le risque ne disparaît pas. Il change d’adresse.
Acheter un SaaS signifie confier une partie de son système et de ses données à un fournisseur, parfois à ses propres sous-traitants, et accepter de nouvelles identités, de nouvelles dépendances et de nouvelles frontières de confiance.
L’emballage commercial, les certifications et les questionnaires de sécurité ne garantissent pas que l’architecture ou les pratiques opérationnelles soient bonnes. Une petite application interne correctement gouvernée peut parfaitement présenter moins de risques qu’un SaaS dont l’acheteur ne maîtrise réellement ni l’architecture ni la chaîne de sous-traitance.
Dans les deux cas, quelqu’un construit.
La question est de savoir selon quelles exigences, sous quel contrôle et avec quelle responsabilité.
La réglementation commence tardivement à s’en apercevoir
Pendant longtemps, une part considérable du risque logiciel a été reportée sur son acheteur. À lui de sélectionner correctement le produit, de le configurer, de l’intégrer, de le surveiller et d’en maîtriser les usages.
Les pouvoirs publics commencent à remettre en cause cet équilibre.
Le Cyber Resilience Act européen impose aux fabricants de produits comportant des éléments numériques des obligations portant sur leur conception, leur développement et le traitement des vulnérabilités pendant leur cycle de vie. Des procédures d’évaluation de conformité sont prévues selon les catégories de produits.
Le Royaume-Uni suit une logique comparable avec son Software Security Code of Practice, qui insiste notamment sur le secure by design et le secure by default.
Le principe paraît presque banal : celui qui fabrique un produit numérique porte lui aussi une responsabilité quant à sa sécurité.
Il aura pourtant fallu attendre que le logiciel devienne une infrastructure omniprésente pour commencer à l’inscrire sérieusement dans les règles.
Et cette prise de conscience arrive précisément au moment où les grandes plateformes franchissent une nouvelle étape : elles ne fournissent plus seulement des logiciels. Elles fournissent à chacun les moyens d’en créer.
Nous vous fournissons le briquet. Veuillez ne pas incendier la maison.
C’est ici qu’apparaît une curieuse asymétrie.
Les éditeurs connaissent parfaitement les risques. Leurs documentations parlent d’environnements de développement et de production, de politiques de données, de contrôle des accès, d’audit, de gestion du cycle de vie et de revue avant publication.
Ils savent qu’une application créée en quelques heures peut devenir critique. Ils savent qu’un connecteur crée de nouvelles circulations de données. Ils savent qu’un agent capable d’agir est d’une autre nature qu’un assistant capable de répondre.
Dans le même temps, leur proposition commerciale tend vers une simplicité radicale : créez, automatisez, connectez, décrivez simplement ce que vous voulez obtenir.
La documentation de gouvernance vient ensuite rappeler, en substance : nous vous fournissons le briquet ; nous savons qu’il peut mettre le feu à la maison ; pensez à établir une politique appropriée concernant l’utilisation des briquets.
Le trait est volontairement forcé. L’asymétrie qu’il révèle l’est beaucoup moins.
Plus un fournisseur rend superflue la compréhension technique nécessaire pour créer un système, plus il devient difficile de considérer que la maîtrise des conséquences relève exclusivement de son client.
Le modèle de responsabilité partagée, devenu familier avec le cloud, devra peut-être s’étendre à une nouvelle couche : la responsabilité partagée de la création de capacités numériques.
Et si la véritable barrière était celle de la mise en production ?
Un laboratoire personnel doit pouvoir rester libre. Une application de productivité individuelle ne nécessite pas un comité d’architecture. Restaurer artificiellement la difficulté de construire serait un formidable retour en arrière.
Mais la situation change lorsqu’une création accède en écriture à un ERP, traite des données sensibles, traverse plusieurs organisations, manipule des identités privilégiées ou devient indispensable au fonctionnement de centaines de personnes.
À ce stade, peu importe qu’elle ait été écrite en Python, assemblée dans Power Apps ou décrite en langage naturel à un agent.
Ce sont ses capacités et les conséquences d’une erreur qui devraient déterminer le niveau de contrôle.
On peut donc imaginer une liberté presque totale d’expérimentation, puis des exigences croissantes avec le rayon d’impact : environnement gouverné, propriétaire identifié, journalisation, revue par une personne qualifiée, séparation des rôles et, pour les systèmes les plus critiques, validation formelle avant publication.
Ce n’est pas un permis pour coder.
C’est reconnaître une distinction que nous appliquons déjà à bien d’autres technologies : le droit d’expérimenter n’est pas le droit d’exposer les autres aux conséquences de son expérimentation.
La compétence n’a peut-être jamais été seulement un moyen de produire
Pendant des années, il fallait savoir construire pour pouvoir construire.
L’intelligence artificielle rompt cette relation. Elle peut supprimer une partie des milliers d’heures autrefois nécessaires pour parvenir au résultat.
Mais l’expérience ne servait pas seulement à produire ce résultat. Elle permettait aussi de reconnaître une architecture fragile, une dépendance dangereuse, un privilège excessif ou cette anomalie presque insignifiante qui indique à celui qui l’a déjà rencontrée que quelque chose ne va probablement pas.
L’IA peut réduire les heures nécessaires pour produire.
Elle ne supprime pas celles qui ont été nécessaires pour apprendre à en mesurer les conséquences.
Nous avons longtemps considéré la compétence technique comme une barrière qui empêchait de produire. Nous découvrons qu’elle était aussi, parfois, une barrière qui empêchait de produire n’importe quoi.
La démocratisation de la création numérique est probablement souhaitable. Rien ne justifie de reconstruire artificiellement les obstacles que le low-code et l’intelligence artificielle permettent enfin de supprimer.
Mais rien ne nous oblige non plus à supprimer avec eux la frontière entre l’expérimentation et la production.
Les régulateurs commencent à appliquer ce raisonnement aux produits numériques. Certaines grandes organisations l’appliquent déjà au développement citoyen. Les éditeurs eux-mêmes disposent d’une partie des mécanismes nécessaires pour gouverner ce qu’ils nous encouragent à créer.
Il reste peut-être à en tirer la conséquence :
plus la barrière technique nécessaire pour créer s’abaisse, plus celle qui protège les autres des conséquences de cette création devient importante.
L’électricité a fini par établir cette distinction.
À mesure que nos systèmes numériques deviennent à la fois plus indispensables, plus complexes et plus faciles à modifier, il serait peut-être temps que l’informatique en fasse autant.
Pour en discuter : me contacter.