Vous générez un tableau de bord avec Claude, vous l’envoyez à votre équipe, et deux heures plus tard les chiffres sont déjà périmés. Pour les rafraîchir, il faut relancer une session, régénérer, repartager. Ce petit agacement vient de disparaître, et la manière dont Anthropic l’a réglé raconte beaucoup sur la forme que prendront les applications pilotées par l’IA.
Il y a peu, nous écrivions qu’Anthropic verrouillait les équipes autour de ses artefacts, ces mini-applications interactives générées dans une conversation et devenues objet de travail partagé. Depuis, l’éditeur a ajouté la brique qui manquait à ce tableau : les données vivantes. Les artefacts de code peuvent maintenant appeler des connecteurs MCP (Model Context Protocol, le protocole ouvert qui relie un modèle à des outils et des sources externes). Concrètement, un artefact n’est plus une photo figée d’un instant, mais une application capable d’aller chercher des informations et de déclencher des actions à la demande.
L’artefact tourne avec les accès du lecteur, pas du créateur
C’est là que se joue l’astuce, et elle mérite qu’on s’y arrête. Quand vous partagez un tel artefact, il ne s’exécute pas avec vos accès à vous, le créateur. Il utilise les connecteurs MCP du lecteur qui l’ouvre. Chacun branche ses propres sources, et l’application affiche ce que ce lecteur-là a le droit de voir.
Reprenons pas à pas. Vous concevez une fois l’artefact : sa logique, sa mise en page, ses appels aux outils. Vous ne le régénérez plus. Chaque personne qui l’ouvre déclenche, de son côté, la récupération des données fraîches via ses propres connecteurs. Le créateur n’a plus à relancer de session pour actualiser quoi que ce soit ; le lecteur, lui, ne voit jamais les données d’autrui. Une analogie tient bien la route : l’artefact fonctionne comme une recette, pas comme un plat déjà cuisiné. La recette est écrite une fois ; les ingrédients, chacun les apporte depuis son propre garde-manger.
Une architecture d’application qui se passe de serveur
Le glissement est plus profond qu’un confort de rafraîchissement. Dans une application classique, il faut un backend : un serveur qui héberge la logique, stocke les clés d’API, interroge les bases, gère les droits de chaque utilisateur. C’est le poste le plus coûteux à construire comme à maintenir.
Ici, ce backend s’évapore. La logique tient dans l’artefact, et l’accès aux données passe par les connecteurs que chaque lecteur a déjà configurés dans son propre environnement Claude. Il n’y a plus de serveur central à provisionner, plus de clés à faire tourner, plus d’infrastructure à surveiller. On esquisse ainsi une catégorie d’applications d’IA sans backend, distribuables d’un simple partage, où l’exécution se répartit sur les postes des utilisateurs plutôt que de se concentrer sur une machine. Le contraste avec la concurrence est net : pour publier une application dans ChatGPT, l’Apps SDK d’OpenAI suppose encore de développer et d’héberger son propre serveur MCP joignable en HTTPS, là où Anthropic s’appuie sur les connecteurs déjà branchés côté lecteur. La fonctionnalité est réservée aux abonnements Pro et Max, ce qui la cantonne pour l’instant à un public d’utilisateurs avancés et d’équipes.
Les droits d’accès changent d’épaules
Cette élégance a une contrepartie qu’il faut nommer. En faisant tourner l’application avec les accès du lecteur, Anthropic déporte aussi la responsabilité des droits vers l’utilisateur final. Le créateur d’un tableau de bord ne maîtrise plus ce que chacun verra : tout dépend des connecteurs que le lecteur a branchés, et des permissions qui y sont attachées.
Pour la confidentialité, c’est plutôt une bonne nouvelle. Le créateur ne peut pas, par construction, exfiltrer les données de ses lecteurs : il ne les voit pas. Chaque personne reste dans son périmètre. Mais la gouvernance se fragmente d’autant. Le même artefact affichera des choses différentes selon qui l’ouvre, ou refusera de fonctionner si le lecteur n’a pas configuré le bon connecteur. Le support, la cohérence de l’expérience, la vérification que « tout le monde voit bien la même chose » : autant de garanties qu’un backend centralisé offrait d’office et qui reposent désormais sur l’équipement de chaque utilisateur.
Prototyper un outil connecté sans monter d’infrastructure
Pour un praticien, l’intérêt est immédiat : brancher un outil interne sur des données réelles devient une affaire de minutes, sans monter la moindre infrastructure. Un tableau de suivi commercial, un assistant qui interroge une base et déclenche une action, un rapport qui se met à jour tout seul chez chacun : ces objets, hier réservés à une équipe de développement, tiennent maintenant dans un artefact partagé.
Restent les angles morts. La dépendance à l’écosystème d’Anthropic se resserre : ces applications ne vivent que dans Claude, avec des connecteurs Claude, pour des abonnés Claude. C’est la continuité directe du verrouillage que nous pointions récemment, poussé un cran plus loin. Et la promesse « sans backend » a ses limites : dès qu’il faut de la persistance, des traitements lourds ou une logique métier complexe, le serveur qu’on croyait avoir supprimé finira par réapparaître quelque part.
Anthropic teste ici, grandeur nature, bien plus qu’une commodité de rafraîchissement : une façon de distribuer des logiciels d’IA où le code voyage librement et où les données ne quittent jamais leur propriétaire. Le pari est séduisant. Il déplace surtout, sans le dire trop fort, la charge de la sécurité et de la cohérence sur les épaules de chaque destinataire, un par un. C’est cette charge diffuse, plus que la question de l’hébergement, qui dira si le modèle tient à l’échelle.
