/// Signal

Keynote et Xcode s’ouvrent aux agents IA — et Apple ne dit pas ce qu’ils pourront y modifier

Le fait : depuis la première bêta de Xcode 27.2, mise en ligne le jeudi 17 septembre 2026, un projet Xcode peut être décrit en JSON au lieu du vieux fichier PLIST, et Apple écrit que ce format est « easier for coding agents to edit ». Le 27 octobre, son communiqué sur Apple Creator Studio a annoncé la même bascule pour Keynote, plus une prise en charge du protocole MCP dans Keynote, Pages et Numbers. Le récit qui a circulé — les développeurs réclamaient, l’IA a débloqué — est en partie vrai. Mais sur la seconde moitié, ce qu’Apple ne dit pas compte plus que ce qu’elle annonce.

Commençons par ce qui est effectivement sorti, et quand. La description d’Apple, reprise le 17 septembre 2026 par Michael Tsai, dit : « Xcode now supports a JSON-based project format (.xcproj) that’s more readable, merge-friendly, and easier for coding agents to edit. Enable it in the file inspector. Projects using .xcproj also open in earlier versions of Xcode 27. » Le nouveau fichier ne remplace pas le paquet de projet : il remplace project.pbxproj, le graphe de construction situé à l’intérieur du paquet .xcodeproj — c’est le développeur Fatbobman qui le relève, dans le même billet. La bascule se fait depuis l’inspecteur de fichiers et reste réversible, le projet continuant de s’ouvrir dans Xcode 27 stable : MacGeneration, qui l’a essayé sur un projet interne le jour de la bêta, l’a vérifié et mesure un fichier « plus de deux fois plus court », environ 400 lignes contre près de 950. Apple a publié sur GitHub apple/xcode-project-format, une bibliothèque Swift sous Apache License 2.0 with Runtime Library Exception avec un outil en ligne de commande, dont l’objectif déclaré est de donner « a shared, accurate model » du format, pour que générateurs, linters, vérificateurs et validateurs « don’t each have to reverse-engineer the format from scratch ».

Les réactions rassemblées par Tsai disent des années d’attente, et elles ne sont pas unanimes — contrairement à ce que Tsai lui-même écrit en présentant le fil comme « universally positive ». Simon B. Støvring : « Developers have been screaming for a friendlier Xcode project format for years. I’m one of them. » Tony Arnold : « I’ve been waiting for something like this for most of my career! » Rob Napier, plus acide : « It does feel like another case of "we’ve quickly done a thing to help AI that we’ve been unwilling to do for years to help humans." I’m seeing that happen across the industry. It is very welcome and appreciated, and lots of thanks to the teams involved. It’s also frustrating that it took "it can help AI" to make it happen. » En face, Helge Heß demande si le sujet ne se déplace pas ailleurs : « Didn’t most people switch to local SPM projects anyways? »

Ce qui bloquait vraiment n’était pas la lisibilité, et cela mérite d’être dit précisément — d’autant que Next l’écrivait déjà le 28 octobre : « Techniquement, le fichier reste lisible par un humain, et donc par un agent IA ». John Gruber, le 22 septembre, formule le problème en une phrase : « While technically that format is a human-readable (and thus LLM-readable) text file, it effectively needed to be treated as a binary file. » Le vieux .pbxproj n’était pas de l’XML mais une liste de propriétés façon NeXT, antérieure non seulement à JSON mais à JavaScript, et le problème n’était pas ce format, « but instead the way the object graph was represented in it ». Tout passait par des identifiants opaques, et une petite modification dans Xcode entraînait des changements à plusieurs endroits du fichier. Fatbobman en tire la conséquence pour les agents : « In the age of agents, the drawbacks of pbxproj are amplified further », parce qu’il faut retrouver le bon objet dans une table plate puis mettre à jour des endroits qui se référencent mutuellement. Ce que le nouveau format change, c’est le passage « from a flat ID table to a tree that mirrors the UI », et le sens des relations s’inverse : un fichier déclare lui-même les cibles auxquelles il appartient. Next dit la même chose autrement : « Le choix du JSON ne fait pas tout : l’organisation des données compte tout autant pour rendre un fichier facile à exploiter. »

Reste que ce format n’est pas forcément celui que réclamait une partie du milieu, et c’est l’objection la plus solide du dossier. Fatbobman résume l’attente autrement : « What the community has actually been waiting years for is a project manifest along the lines of Package.swift: something written by people, read by people, and reviewed by people, rather than a more modern encoding of the IDE’s internal database. » Un fichier de configuration que l’humain écrit et relit, donc. Une seconde critique, celle de tim le 18 septembre, portait sur la documentation : « I don’t even see documentation of the format. There’s just a Swift library for it. » Chris Hanson a répondu que cette documentation existe, dans la bibliothèque et publiée sur le Swift Package Index. Le même commentateur est le seul du fil à chiffrer l’attente, et il faut lire ce qu’il chiffre : Apple, écrit-il, a « just been ignoring them for the past 20+ years » — et « them », ce sont les conflits de fusion, pas la demande d’un format lisible. Un autre intervenant, Sören, note que le nouveau format « makes it easier for developers to hand-edit the files » — avant d’ajouter sa réserve : « The new format seems better, but still a far cry from e.g. XcodeGen. »

Le seul témoignage venu de l’intérieur d’Apple doit être lu avec ses deux réserves, pas une. Chris Hanson écrit avoir été responsable du format de projet « for a portion of that time », jusqu’à sa retraite en 2024, et répond à l’accusation d’immobilisme : « It’s incorrect to say that Apple has just been ignoring them. For a portion of that time, I was responsible for the project file format, and reducing merge conflicts was always something we were working towards. » Il ajoute que, pour ce qui le concerne, l’IA n’y était pour rien : « Oh, and I can assure everyone that when I was working on this stuff, making anything easier to use with LLM-based tooling was not one of my considerations. » Mais il précise aussi qu’il ne sait pas si le format livré en 2026 vient de son travail : « (I don’t know if the shipped JSON format is based on my work or is new work, or a bit of both.) » Son témoignage décrit donc l’histoire longue du format, pas la raison de celui qui est sorti deux ans après son départ.

La seconde moitié du sujet, Keynote, est celle où le compte n’y est pas. Le communiqué du 27 octobre 2026 annonce, dans la mise à jour d’Apple Creator Studio attendue en novembre, deux choses distinctes. La première est le format .keyx, « Keynote Interchange », décrit comme « un format de fichier groupé ouvert, basé sur JSON, conçu pour être lisible et accessible aux outils externes, aux workflows de développeurs et aux agents d’IA ». La seconde est la prise en charge du protocole MCP (Model Context Protocol) dans Keynote, Pages et Numbers, qui « permet à des outils et agents d’IA externes de lire du contenu, d’effectuer des modifications et d’exécuter des actions automatisées directement » dans ces trois applications, avec macOS 27 comme prérequis. Next, qui couvre le format le 28 octobre, ne dit pas un mot du protocole ; MacGeneration le mentionne en une ligne — « un serveur MCP, pour faciliter le travail des agents dans ses fichiers ». heise online, lui, y consacre un développement, et c’est la partie qui manque partout ailleurs : « Apple’s announcement doesn’t say whether Freeform will also get an MCP interface, or whether access will need to be approved per document, agent or session and changes confirmed. Apple also hasn’t explained how it will prevent unwanted changes or document content from being leaked, which AI model will handle which requests, or when content leaves the device. » Trois applications qui contiennent des documents de travail, une porte ouverte sur leur contenu, et pas un mot sur ce qu’un agent venu du dehors a le droit d’y toucher. heise ajoute une seconde question, de périmètre celle-là : « Apple hasn’t said which new features, such as the MCP interface, will also be available without a subscription. » Et la contrepartie n’est pas la même pour tout le monde : l’assistant intelligent, qui comprend le document ouvert et peut le réorganiser, est selon MacGeneration « réservé aux abonnés Apple Creator Studio », en bêta et uniquement en anglais américain.

Reste la disponibilité, et là le dossier répond — contrairement à ce que nous écrivions dans une première version de cet article. Next écrit que le format .keyx est « pas encore disponible ». MacGeneration, le 28 octobre, est plus précis : « Du fait de ce décalage, on ne peut pas encore tester le nouveau format de fichiers de Keynote et vérifier en quoi il consiste exactement », et « ce changement n’est pas encore effectif ». Un article de MacGeneration du 22 octobre affirmait pourtant l’inverse, en écrivant que Keynote « peut désormais importer et exporter des présentations au format .keyx » et que la nouveauté « concerne tous les utilisateurs de Keynote ». Le communiqué d’Apple porte lui-même la contradiction qui explique probablement tout : il écrit au présent que « Keynote prend désormais en charge » le format, puis date la disponibilité de novembre. Nous ne disons donc pas que Keynote traite le fichier .keyx aujourd’hui. Pour Keynote, l’ouverture n’est d’ailleurs pas une première : en 2003 la première version s’appuyait sur APXL, un fichier XML (Next), et Steve Jobs vantait déjà un format ouvert pour automatiser la création de diapositives (MacGeneration) avant qu’Apple ne bascule en 2013 vers une structure interne difficile à exploiter hors de Keynote (Next). Vingt-trois ans plus tard, le même argument revient — adressé aux agents.