Les agents IA pourraient remplacer les applications traditionnelles par des systèmes vérifiés et construits par les utilisateurs

Les agents IA pourraient faire de l'exécution de code écrit par des inconnus l'une de ces comportements que les générations futures auront du mal à comprendre.

Une société peut normaliser un risque pendant des décennies, puis le réclassifier comme imprudent une fois qu'une option par défaut plus sûre devient disponible.

Boire avant de conduire, rouler sans ceinture de sécurité, fumer à l'intérieur et installer des binaires arbitraires provenant d'Internet appartiennent tous à la même famille de lacunes historiques. La caractéristique commune est la permission sociale.

Le comportement persiste lorsque l'alternative est coûteuse, inconfortable ou techniquement indisponible. Une fois que le chemin plus sûr devient peu coûteux et courant, l'ancien chemin semble irrationnel.

Les logiciels modernes fonctionnent toujours sur une transaction avantageuse que nous examinons rarement. Un développeur, une entreprise, une fondation ou un mainteneur anonyme écrit du code. Un canal de distribution le conditionne. Un utilisateur, une entreprise ou un système d'exploitation l'exécute.

La sécurité devient alors une approche en couches visant à gérer les conséquences de cette décision.

Les autorisations, la signature de code, les applications, la détection des points d'extrémité, l'isolation, la diligence raisonnable des fournisseurs et la réponse aux incidents existent parce que l'acte fondamental reste dangereux : exécuter les instructions de quelqu'un d'autre sur votre machine, dans votre compte, avec accès à vos données.

Ce modèle de confiance a échoué à l'échelle institutionnelle. La compromission de SolarWinds a montré comment du code malveillant introduit dans un processus de construction logicielle de confiance pouvait être distribué via des mises à jour normales et atteindre des agences gouvernementales, des entreprises technologiques, des réseaux de télécommunications et d'autres cibles à travers plusieurs régions.

La leçon opérationnelle était structurelle, et la surface d'attaque était la légitimité du fournisseur lui-même.

Une fois le processus de compilation compromis, les signes normaux de confiance sont devenus l'infrastructure de livraison pour l'attaque.

Le même schéma est apparu dans le XZ Utils backdoor, où la CISA a averti en mars 2024 qu'un code malveillant avait été intégré dans les versions 5.6.0 et 5.6.1 d'une bibliothèque de compression présente sur les distributions Linux.

La National Vulnerability Database a ensuite décrit comment un fichier de test déguisé et une manipulation du processus de compilation ont produit une bibliothèque liblzma modifiée capable d'intercepter et de modifier les interactions de données dans les logiciels liés.

Une chaîne d'approvisionnement logicielle peut être compromise bien en amont de l'utilisateur, puis arriver par des canaux qui semblent routiniers. Nous l'avons vu nombre de fois en crypto avec des exploitations DNS et JavaScript npm.

La réponse de l'industrie a consisté à mettre en place un processus plus rigoureux. Le NIST Secure Software Development Framework fournit aux organisations un ensemble commun de pratiques pour développer et acquérir des logiciels avec un risque réduit.

Le SLSA framework intègre la traçabilité, l'intégrité et la résistance à la falsification dans le pipeline d'artefacts. Ces contrôles sont nécessaires.

Ils révèlent également les limites du modèle actuel. Les entreprises continuent d'affiner les méthodes pour déterminer quel code externe mérite confiance.

Le modèle suivant réduit le montant de code externe qui nécessite une confiance.

Ce changement modifie le sens social du logiciel. Aujourd'hui, le code tiers est considéré comme un atout de productivité avec un surcoût en matière de sécurité.

Demain, cela pourrait être considéré comme une responsabilité qui nécessite une justification. La question par défaut de l'utilisateur passe de « Quelle application devrais-je installer ? » à « Pourquoi devrais-je exécuter une application d'autrui lorsque mon agent peut créer la fonction pour moi ? »

C'est une véritable ligne de fracture. Le logiciel cesse d'être principalement un produit sélectionné sur un marché pour devenir une sortie générée sur demande dans un environnement d'exécution contrôlé par l'utilisateur.

La direction du déplacement est visible dans les agents de codage. OpenAI Codex a été introduit comme un agent d'ingénierie logicielle basé sur le cloud capable de gérer plusieurs tâches en parallèle.

Claude Code d'Anthropic est un système de codage agente qui cartographie une base de code, modifie des fichiers, exécute des tests et fournit du code validé.

l'agent de codage Copilot de GitHub a déplacé le même motif dans le workflow GitHub, avec un travail asynchrone à travers les problèmes et les demandes de tirage.

Google Jules propose une direction similaire : un agent de codage autonome qui absorbe le contexte produit, génère des solutions et soumet des pull requests.

Ces produits sont toujours présentés comme des outils pour développeurs. Ce cadre se rétrécira avec le temps. Pour Codex, c'est déjà le cas. OpenAI a introduit l' mois dernier une option d'interface utilisateur axée sur les « discussions » et les sorties, plutôt que sur le code et les terminaux.

Le changement plus important est que la création de logiciels devient un acte personnel de délégation de validateurs. Un utilisateur décrit un flux de travail. L'agent génère l'interface, la logique, les intégrations, les tests et le chemin d'exécution.

L'artefact peut durer une heure, une semaine ou un an. Il peut être régénéré, forké, contraint, audité, éliminé ou reconstruit pour un nouveau contexte.

L'application devient de moins en moins un objet permanent et de plus en plus une politique locale intégrée dans une interface utilisable.

Cela a des implications immédiates sur la confiance. Un utilisateur peut toujours observer les applications d'autres personnes. Il peut examiner les flux de travail, les modèles d'interface, les schémas de données, les invites, les automatisations et les intégrations de services. Toutefois, l'observation peut rester séparée de l'exécution.

L'utilisateur peut copier l'idée, puis demander à un agent personnel de reconstruire la fonction à partir de principes fondamentaux dans un environnement régi par ses propres règles. La valeur migre de l'artefact compilé au modèle.

La distribution devient moins axée sur l'envoi de code exécutable et davantage sur la publication d'intentions, de conceptions, de preuves, de schémas et d'attentes concernant les API.

La cryptomonnaie entre dans l'argument par la vérification plutôt que par la marque. L'agent de l'utilisateur continuera de se connecter à des services externes.

Il peut appeler les infrastructures de paiement, les systèmes d'identité, les points de terminaison de données de marché, les couches de stockage, les fournisseurs de modèles d'IA, les marchés de calcul, les systèmes de messagerie et les services de conformité. La limite de confiance se déplace vers ces points de terminaison et les revendications formulées à leur sujet.

Les utilisateurs auront besoin de moyens pour classer les services externes en fonction de leur traçabilité, de leur provenance, de leur posture de sécurité et de leur alignement économique. Un service construit dans un environnement vérifiable sera évalué différemment d’un point de terminaison en boîte noire contrôlé par une plateforme corporative.

Les systèmes à preuve à connaissance nulle offrent une voie d'accès à cette couche de classement. ZK rollups montrent comment le calcul peut être exécuté hors chaîne tandis qu'une preuve concise vérifie la validité de la transition d'état résultante sur chaîne.

Le même modèle conceptuel peut s'étendre au-delà de la mise à l'échelle des transactions. Les utilisateurs peuvent souhaiter des preuves qu'un point de terminaison a exécuté un code approuvé, traité des données dans le cadre de contraintes définies, préservé les limites de confidentialité ou produit un résultat à partir d'une compilation spécifique auditée.

La preuve peut préserver la confidentialité interne tout en réduisant l'écart de confiance entre un agent personnel et une dépendance externe.

L'interface à long terme peut ressembler à une couche d'exploitation contrôlée par un agent. L'utilisateur demande un tableau de bord, un outil de portefeuille, un assistant de recherche, un système de publication, un CRM personnel, un processus de comptabilité ou un moniteur de sécurité.

L'agent le assemble à partir du code généré et des points de terminaison classés. Le code est inspectable car l'agent l'a créé.

Les dépendances sont contraintes car l'agent les a sélectionnées selon la politique. L'environnement d'exécution est auditables car l'utilisateur l'a choisi comme exigence.

L'utilisateur continue de participer à une économie réseau. Le contrôle se rapproche de l'individu.

La fin de cette transition est un marché pour des fonctions vérifiables, des clients générés par des agents et des services externes classés. Les développeurs tiers existent toujours, mais leur rôle change.

Ils publient des protocoles, des API, des modèles, des preuves, des modèles, des composants et des implémentations de référence. Les utilisateurs exécutent leurs propres versions.

Les entreprises existent toujours, mais leur avantage passe du contrôle de la distribution à la démonstration de fiabilité. Les communautés open-source existent toujours, mais la charge passe de demander aux utilisateurs de faire confiance aux maintainers à fournir aux agents suffisamment de matériel structuré pour reconstruire en toute sécurité.

L'ancienne économie logicielle vendait des applications finies. La nouvelle vend des capacités crédibles.

Un suivi de portefeuille devient une interface générée à partir des points de terminaison de données de marché, des autorisations de wallet, de la logique fiscale et des règles de reporting. Un système de publication devient un flux de travail généré à partir des API d'identité, d'édition, de gestion de contenu, d'analyse et de distribution.

Un terminal de recherche devient une surface générée à partir de bases de données, d'appels de modèles, de vérifications de provenance et de notes privées. Dans chaque cas, l'agent de l'utilisateur gère la composition.

Le monde externe fournit des ressources vérifiables. Ce changement crée également un test commercial pour chaque fournisseur d'infrastructure : prouver l'affirmation, publier l'interface, exposer l'ensemble des contraintes, et laisser les agents côté utilisateur décider si le service mérite d'être inclus.

Le débat habituel oppose l'avenir local au cloud. Cette division capture une partie de la question de l'infrastructure, tout en ignorant l'économie politique.

Un système privé peut utiliser le calcul cloud dans le cadre de contraintes définies par l'utilisateur. Un système corporatif peut fonctionner localement tout en intégrant l'identité, les incitations, les autorisations et la monétisation au sein d'une pile contrôlée par un fournisseur.

La séparation la plus durable est entre privé et corporate. Qui définit l'application ?

Qui décide de ce qu’il peut accéder ? Qui reçoit les données de télémétrie ?

Qui définit le chemin de mise à jour ? Qui peut révoquer la fonction ?

Qui bénéficie de la dépendance de l'utilisateur ?

Cette séparation deviendra plus visible à mesure que les logiciels agents deviendront suffisamment abordables pour les utilisateurs ordinaires. Un chemin mène vers la souveraineté logicielle personnelle.

Les utilisateurs gèrent des agents qui construisent et reconstruisent les outils dont ils ont besoin. Ils choisissent les fournisseurs de points de terminaison en fonction des attestations, du coût, de la fiabilité, de la confidentialité et de l'alignement.

Ils peuvent abandonner une interface tout en préservant le flux de travail sous-jacent. Ils peuvent migrer d’un point de terminaison à un autre.

Ils peuvent générer un nouveau client lorsqu'un ancien est compromis, capturé ou inefficace. La couche logicielle devient portable car l'utilisateur possède l'intention, et l'agent peut reproduire l'implémentation.

L'autre voie mène vers une commodité gérée. Les plateformes corporatives proposeront des applications subventionnées, une identité intégrée, des crédits, des paiements, un stockage, un accès à l'IA et des flux de travail par défaut.

Une partie de cela sera utile. Une partie sera économiquement coercitive.

Si l'abondance pilotée par l'IA génère des systèmes de revenu proches de l'UBI public ou privé, des crédits de calcul, des distributions de jetons ou des avantages liés à la plateforme, le canal de distribution peut devenir un mécanisme de verrouillage doux. Les utilisateurs peuvent obtenir l'accès à des services via un écosystème qui définit également quel logiciel ils exécutent, comment leurs données circulent et quels agents peuvent agir en leur nom.

La couche UBI est la version la plus sensible de ce problème. Sam Altman est depuis longtemps associé aux débats de l'ère de l'IA sur la répartition des revenus, et Worldcoin a été présenté, en partie, autour de la preuve d'identité humaine et de la possibilité de distributions similaires à un RBI.

Le point plus vaste dépasse un seul projet. Lorsque le soutien économique, la vérification d'identité, l'accès au calcul et les autorisations logicielles convergent, la participation peut devenir conditionnelle tout en semblant volontaire.

Un utilisateur peut théoriquement être libre de refuser, mais se voit poussé vers une couche d'application gérée en pratique.

La commodité devient le principal champ de bataille. La pile corporative gagnera les utilisateurs grâce à une faible friction.

Il proposera des paramètres par défaut optimisés, un accès instantané, une IA intégrée, une compatibilité sociale, des processus de récupération, une couverture de conformité et des récompenses. La pile privée devra se distinguer par quelque chose de plus difficile : une autonomie qui semble utilisable.

Il doit offrir aux utilisateurs une raison d'accepter davantage de responsabilités tout en évitant l'administration technique. L'agent personnel devient décisif car il peut absorber la complexité qui rendait auparavant la souveraineté impraticable.

Le risque de premier ordre est que les utilisateurs échangent le contrôle contre la commodité avant de comprendre le coût. Le risque de second ordre est que cet échange devienne subventionné, normalisé, puis finalement obligatoire pour accéder à la vie économique.

Les applications corporatives peuvent devenir l’environnement par défaut pour ceux qui acceptent des avantages regroupés. Les applications générées de manière privée peuvent devenir la norme pour ceux disposés à payer, vérifier, configurer ou assurer la auto-gestion de leur couche logicielle.

Cela crée une nouvelle division de classe autour du contrôle de l'exécution. La question est de savoir si l'IA agente comprime cette division ou la creuse.

Cette transition sera inégale. Les secteurs réglementés évolueront plus lentement.

Les entreprises défendront les écosystèmes d'applications en invoquant des arguments de conformité. Les consommateurs continueront de privilégier la commodité par défaut lorsque l'alternative privée semble fragile.

Les attaquants cibleront les agents, les invites, la sélection des dépendances, les chaînes d'approvisionnement des modèles et les attestations de point final. Les systèmes de vérification créeront de nouveaux points de blocage s'ils sont capturés par un petit nombre d'autorités de certification, de plateformes cloud ou de fournisseurs de modèles.

La souveraineté logicielle personnelle peut devenir une autre revendication marketing si les utilisateurs ne peuvent pas inspecter, migrer et révoquer.

Pourtant, la direction est suffisamment claire pour définir le prochain test. La question est de savoir si les gens accepteront la commodité au détriment de la souveraineté une fois que leurs propres agents pourront construire la majeure partie de ce dont ils ont besoin.

Aujourd'hui, la réponse est largement oui car l'alternative reste trop exigeante. Demain, la réponse devient moins certaine.

Un utilisateur qui peut générer une application fonctionnelle, limiter ses autorisations, auditer ses dépendances, se connecter uniquement à des points de terminaison classés, et la reconstruire lorsque les conditions changent dispose d'une alternative réelle au pack de logiciels corporatifs.

Cette alternative semblera étrange au début. Ensuite, elle semblera prudente.

Ensuite, cela pourrait devenir l'attente par défaut pour toute personne gérant de l'argent, des identités, des données de santé, des communications privées, des recherches ou des opérations commerciales. L'exécution de code tiers opaque survivra lorsque la commodité prime, lorsque les subventions déforment le choix et lorsque les utilisateurs acceptent des environnements gérés en échange d'un accès économique.

Il s'estompera là où les agents effectuent une routine de génération privée.

La réclassification sociale se produira lentement, puis soudainement. L'ancienne habitude restera familière jusqu'à ce que le nouveau comportement par défaut devienne évident.

Une fois que les utilisateurs pourront demander à leurs propres agents de construire l’application, de vérifier le chemin d’exécution et de se connecter uniquement à des points de terminaison attestés, la charge de l’explication s’inversera. La personne exécutant le code d’autrui devra avoir une raison.

La personne qui construit via un agent utilisera simplement l’option par défaut plus sûre. Toutefois, elle devra peut-être accepter de manquer des incitations corporatives accordées à ceux qui restent connectés à la matrice.

Le post Les jours des applications sont comptés : l'état final du logiciel sera privé, personnel, vérifié et construit par des agents IA est apparu en premier sur CryptoSlate.