iOS 27 Siri AI : guide de migration et de test pour les apps

Les équipes qui maintiennent une application iPhone avec des actions SiriKit doivent désormais préparer une adaptation de Siri AI à iOS 27 sans casser les parcours existants. La bonne approche n’est pas de tout réécrire d’un coup : il faut classer les actions, modéliser les entités avec App Intents, choisir les schémas Apple adaptés, puis vérifier séparément Siri, Raccourcis, Spotlight et le contexte à l’écran. Ce guide vous fournit une méthode de migration, un exemple d’application de calendrier et une procédure de test reproductible sur Xcode 27.

Pourquoi l’adaptation de Siri AI à iOS 27 exige une vraie migration

Avec Siri AI, l’application n’est plus seulement appelée à partir d’une phrase prédéfinie. Le système doit pouvoir comprendre vos actions, rechercher vos contenus, transmettre certaines données entre apps et interpréter une demande formulée de manière moins rigide.

Apple décrit App Intents comme le framework moderne permettant de rendre les actions d’une app découvrables par Siri, Apple Intelligence, Raccourcis et d’autres surfaces du système. SiriKit et les frameworks historiques restent utiles pour la compatibilité, mais Apple les présente désormais comme une solution héritée pour les interactions Siri, les actions Raccourcis et certains widgets. Pour les nouvelles intégrations, App Intents devient donc le point de départ logique. Documentation Apple sur App Intents (developer.apple.com)

Une app non adaptée ne disparaît pas automatiquement de l’iPhone, mais elle peut perdre plusieurs occasions d’être utilisée :

1. Actions moins découvrables : Siri comprend moins bien les capacités qui ne sont exposées que par des intentions anciennes ou des phrases fixes.
2. Recherche de contenu incomplète : un événement, une note, une photo ou un document peut rester invisible dans Spotlight si l’entité n’est pas correctement indexée.
3. Opérations interapps limitées : le système ne dispose pas d’un type transférable clair pour transmettre une personne, une date, un fichier ou une entité métier à une autre application.
4. Contexte écran absent : l’utilisateur peut dire « ajoute ce rendez-vous » ou « ouvre cette vidéo », mais Siri ne saura pas nécessairement à quel élément visible il fait référence.
5. Permissions mal contrôlées : une action de suppression, de partage ou de modification peut être exécutée sans le niveau de confirmation attendu si le modèle de données ne définit pas correctement la propriété de l’entité.

L’enjeu est donc fonctionnel, mais aussi organisationnel : le développeur iOS, le responsable technique et l’équipe de test doivent partager une même cartographie des actions et des données exposées.

SiriKit, App Shortcuts et App Intents : quel choix pour votre projet

Les trois mécanismes ne répondent pas exactement au même besoin. La décision dépend de l’âge du projet, de la stabilité des actions existantes et du niveau d’intégration recherché avec Siri AI.

Pour un ancien projet, ne supprimez pas les six actions SiriKit existantes avant d’avoir vérifié leur usage dans les versions actuellement distribuées. Une migration progressive est généralement plus sûre : vous conservez l’ancien parcours, vous créez son équivalent App Intent, puis vous comparez les résultats et les permissions.

Les App Shortcuts restent utiles pour présenter une action dans Raccourcis avec un nom et des paramètres clairs. Ils ne doivent toutefois pas être confondus avec le modèle de données complet attendu par Siri AI. Si l’utilisateur doit rechercher une entité, la modifier, la transmettre à une autre app ou la retrouver dans Spotlight, App Intents doit devenir votre couche principale.

Construire le modèle métier avant d’écrire le code

La première étape de cette adaptation n’est pas d’ajouter une macro Swift. Elle consiste à faire l’inventaire de ce que votre app sait réellement faire.

Prenons le cas d’une application de calendrier utilisée par une équipe de quatre personnes. Son produit possède six actions SiriKit :

• créer un événement ;
• rechercher un événement ;
• déplacer un événement ;
• afficher l’agenda du jour ;
• ajouter un participant ;
• supprimer un événement.

Avant toute migration, l’équipe doit documenter pour chaque action le verbe, les paramètres obligatoires, les paramètres facultatifs, les permissions, le résultat affiché et le niveau de risque.

Une action comme « afficher mon agenda du jour » est généralement une bonne candidate pour une première migration. Elle est consultative, son résultat est facile à vérifier et elle peut tirer profit de la recherche sémantique. À l’inverse, « supprimer un événement partagé » doit être traitée plus prudemment : l’entité doit exposer sa propriété ou son niveau d’appartenance, et l’intention doit prévoir une confirmation explicite.

Apple recommande d’utiliser les schémas App définis pour les domaines connus, notamment le calendrier, les messages, les fichiers, les photos, les notes et les rappels. Ces schémas servent de contrat entre votre app et le système : ils aident Siri AI à reconnaître la structure de l’action et les expressions naturelles associées. Présentation des domaines de schémas App (developer.apple.com)

Votre tableau interne devrait au minimum contenir les colonnes suivantes :

• action métier ;
• ancienne intention SiriKit ;
• nouvel App Intent ;
• entité ou énumération utilisée ;
• schéma Apple correspondant ;
• permission requise ;
• résultat attendu ;
• test positif ;
• test négatif ;
• confirmation obligatoire ou non.

Cette étape évite une erreur fréquente : migrer les noms d’actions sans migrer la qualité des données transmises au système.

Un App Intents tutoriel appliqué à une application de calendrier

Pour commencer, créez une entité représentant l’événement de calendrier. Elle doit posséder un identifiant stable, un titre, une date de début, une date de fin, un calendrier associé et, si nécessaire, une indication sur son propriétaire.

L’objectif est que Siri puisse distinguer :

• « la réunion produit de lundi » ;
• « l’événement avec Claire » ;
• « le rendez-vous visible à l’écran » ;
• « le prochain événement du calendrier professionnel ».

Un AppEntity trop pauvre, limité à un identifiant et un nom, fonctionnera dans une démonstration simple mais échouera dès qu’il faudra désambiguïser plusieurs résultats. Exposez donc les propriétés utiles à la recherche, sans publier les informations confidentielles qui ne sont pas nécessaires à l’action.

Ensuite, créez un App Intent pour une opération peu risquée, par exemple l’affichage d’un événement :

struct ShowCalendarEventIntent: AppIntent {
    static var title: LocalizedStringResource = "Afficher un événement"

    @Parameter(title: "Événement")
    var event: CalendarEventEntity

    func perform() async throws -> some IntentResult {
        return .result(
            opensIntent: OpenCalendarEventIntent(event: event)
        )
    }
}

Dans un projet réel, le type CalendarEventEntity doit fournir une requête capable de rechercher les événements et de retourner des suggestions compréhensibles. L’action doit également renvoyer un résultat exploitable par Siri ou Raccourcis, plutôt qu’un simple succès silencieux.

Pour une création d’événement, séparez les paramètres selon leur rôle :

• titre obligatoire ;
• date et durée ;
• calendrier cible ;
• participants ;
• lieu ou lien de visioconférence ;
• rappel facultatif.

Cette séparation aide le système à demander uniquement les informations manquantes. Elle facilite aussi les tests de paramètres partiels : « crée un rendez-vous demain matin » ne fournit pas forcément un titre, une durée ou un calendrier.

Pour les actions correspondant à un domaine Apple, utilisez le schéma approprié plutôt que d’inventer une structure propriétaire lorsque cela est possible. Les schémas définissent les paramètres et les résultats attendus, et Xcode peut signaler certaines incohérences lors de la compilation. (developer.apple.com)

Adapter Siri aux opérations entre applications et au contexte écran

La Siri interapp opération repose sur deux conditions : les données doivent être décrites avec un type compréhensible, et leur transfert doit respecter les permissions de l’utilisateur.

Imaginons le scénario suivant : l’utilisateur consulte un événement dans votre calendrier, puis demande à Siri de créer une note de préparation dans une app de notes. Votre application doit rendre l’événement identifiable et transférable. Le système doit également savoir quelles informations peuvent sortir de votre app : titre, date, participants ou lien de réunion ne présentent pas tous le même niveau de sensibilité.

Apple indique que Siri AI peut utiliser les entités indexées dans Spotlight pour retrouver du contenu, mais aussi des types transférables pour déplacer des données entre applications. L’association entre une entité et une activité utilisateur permet en outre de fournir un contexte lié au contenu visible à l’écran. (developer.apple.com)

Procédez dans cet ordre :

1. Définissez l’AppEntity correspondant au contenu visible.
2. Ajoutez un identifiant stable et une représentation lisible.
3. Rendez les propriétés nécessaires disponibles pour l’indexation.
4. Associez l’entité à la vue ou à l’activité utilisateur concernée.
5. Implémentez la représentation transférable uniquement pour les données réellement nécessaires.
6. Testez le même scénario avec une entité privée, une entité partagée et une entité inexistante.
7. Ajoutez une confirmation pour les suppressions, modifications sensibles ou actions sur des ressources partagées.

Ne supposez pas que la présence d’un élément à l’écran autorise son export. Le contexte aide Siri à comprendre « cet événement » ou « cette vidéo », mais il ne contourne ni les autorisations d’accès ni les règles de confidentialité de votre application.

Les mises à jour App Intents de 2026 mettent également en avant IndexedEntity, SyncableEntity, les représentations transférables et les mécanismes de confirmation pour les entités sensibles ou partagées. Ce sont des points à vérifier dans votre architecture si l’application fonctionne sur plusieurs appareils ou manipule des données collaboratives. (developer.apple.com)

Une procédure de test App Intents en cinq niveaux

Un test Siri complet ne doit pas être votre premier test. Vous gagnerez du temps en validant chaque couche séparément.

1. Tester l’intention directement dans Xcode

Commencez par vérifier l’initialisation de l’intention, la résolution de chaque paramètre et le résultat retourné. Utilisez des données déterministes : un événement connu, un identifiant inexistant, une date sans résultat et deux événements portant le même titre.

Contrôlez aussi les erreurs attendues. Une entité absente doit produire une réponse exploitable, pas un échec générique difficile à diagnostiquer.

2. Tester les App Shortcuts et Raccourcis

Ajoutez l’action à Raccourcis et exécutez-la avec :

• tous les paramètres ;
• uniquement les paramètres obligatoires ;
• une valeur ambiguë ;
• une valeur dans une autre langue ;
• une permission refusée.

Cette phase permet de distinguer une erreur dans l’App Intent d’un problème d’interprétation vocale.

3. Tester l’indexation Spotlight

Après l’installation de l’app, vérifiez que les entités attendues apparaissent dans Spotlight. Pour une application de calendrier, testez le titre, le nom d’un participant, le lieu et une date.

Dans le cas de notre équipe de quatre personnes, la migration a d’abord semblé fonctionnelle : les actions de création et d’ouverture répondaient correctement. En revanche, Spotlight ne retrouvait qu’une partie des événements. L’analyse a montré que les entités étaient créées, mais que certains champs utilisés par la recherche n’étaient pas déclarés comme propriétés indexables. Le test Siri avait donc masqué un défaut de modèle de données.

4. Tester le contexte à l’écran

Ouvrez un événement, une fiche de participant ou une vue de détail, puis demandez une action qui désigne le contenu par une expression comme « cet événement ». Recommencez après une navigation, un changement d’onglet et une mise à jour des données.

L’objectif est de vérifier que l’entité visible reste associée à la bonne vue et que l’application ne renvoie pas un objet obsolète.

5. Tester Siri de bout en bout

Terminez par des phrases naturelles, avec des variations de formulation. Vérifiez le comportement lorsque :

• le système demande une précision ;
• l’utilisateur refuse une permission ;
• deux entités correspondent à la demande ;
• l’action nécessite une confirmation ;
• l’application est fermée ;
• l’action est déclenchée depuis une autre app ;
• le réseau de l’application métier est indisponible.

Cette méthode constitue une véritable App Intents testing checklist. Elle sépare les défauts de schéma, de recherche, d’interface et d’exécution au lieu de tout attribuer à Siri.

Les erreurs les plus courantes et leur méthode de résolution

Siri ne trouve pas une entité

Vérifiez d’abord l’identifiant stable, le nom affiché et la requête de recherche. Comparez ensuite les données présentes dans votre base locale avec celles envoyées à Spotlight. Une entité créée uniquement en mémoire ou indexée avant la fin de sa synchronisation peut être absente des résultats.

Le bon schéma ne déclenche pas la bonne action

Un schéma Apple ne sert pas seulement à documenter votre code. Il influence la manière dont le système comprend l’action. Si votre intention de calendrier est décrite comme une action générique alors qu’un schéma de domaine existe, Siri peut avoir du mal à rapprocher la phrase de l’opération attendue.

Un paramètre est toujours demandé

Examinez la définition du paramètre, sa valeur par défaut et la qualité de son type. Un simple texte est souvent trop vague pour une date, une personne, un calendrier ou une entité métier. Préférez une entité ou une énumération quand le système doit proposer des choix.

L’action fonctionne dans Raccourcis mais pas avec Siri

Raccourcis peut exécuter une action avec des valeurs déjà renseignées. Siri doit, lui, comprendre la phrase, trouver les entités et résoudre les paramètres. Reproduisez donc le scénario avec des formulations variées et vérifiez les suggestions de paramètres.

La fonction marche sur un appareil mais pas dans un autre environnement

Comparez la version de l’OS, la version de Xcode, les données de test, la région, la langue, les autorisations et l’état du compte Apple. Une version bêta peut également modifier le comportement d’une surface système. Documentez le numéro de build exact dans chaque rapport de test, au lieu d’écrire simplement « iOS 27 ».

Isoler l’environnement Xcode 27 sans bloquer le Mac principal

Pour une équipe mobile, l’adaptation Siri AI touche souvent les certificats, les simulateurs, les versions de SDK, les données Spotlight et les réglages de confidentialité. Installer une préversion sur le Mac utilisé quotidiennement peut créer un coût de retour arrière disproportionné.

Dans ce contexte, un Mac distant dédié peut servir d’environnement de compatibilité temporaire. La configuration standard actuellement affichée par ZovCloud comprend un Mac mini M4 physique avec processeur à 10 cœurs, 16 Go de mémoire unifiée, SSD NVMe de 256 Go et bande passante dédiée de 1 Gbit/s. Les nœuds proposés incluent notamment Tokyo et la côte Est des États-Unis, sans supplément régional annoncé. (zovcloud.com)

Pour le cas de l’équipe de calendrier, le protocole peut être organisé ainsi :

1. Créer une branche dédiée à l’adaptation iOS 27.
2. Déployer l’environnement sur un Mac séparé.
3. Installer Xcode 27 et conserver la version exacte dans un fichier de référence.
4. Importer uniquement les certificats et profils nécessaires aux tests.
5. Charger un jeu de données anonymisé contenant événements personnels, partagés et ambigus.
6. Tester le nœud de Tokyo pour les membres situés en Asie et le nœud américain pour les parcours nord-américains.
7. Exporter les journaux de test, les captures d’écran et les résultats Spotlight avant de libérer la machine.

La tarification affichée le 21 juillet 2026 indique une location journalière à partir de 19,80 $, une formule hebdomadaire à 53,50 $, une formule mensuelle à 99,10 $ et une formule trimestrielle à 269,60 $. La mise à disposition annoncée est généralement de 1 à 5 minutes, avec accès par VNC navigateur, SSH ou client VNC tiers. Ces éléments correspondent aux données publiées par ZovCloud et doivent être revérifiés avant commande. (zovcloud.com)

Pour cinq jours de validation, la formule journalière représenterait environ 99,00 $ hors option, tandis qu’une location hebdomadaire à 53,50 $ couvre un sprint complet de compatibilité. Le choix dépend donc moins de la puissance brute que de la durée réelle de la campagne, du nombre de développeurs et de la nécessité de conserver l’environnement entre deux cycles de test.

Vous pouvez comparer les cycles dans les tarifs de location d’un Mac cloud ou consulter le guide Mac cloud pour Xcode et la CI/CD si vos tests Siri doivent ensuite être intégrés à un pipeline de compilation.

La décision pratique pour votre feuille de route

Si votre app possède déjà SiriKit, ne lancez pas une réécriture générale. Commencez par les actions les plus visibles et les plus utiles : recherche d’entités, ouverture de contenu, création d’éléments et opérations interapps. Conservez les intentions historiques tant que la compatibilité n’est pas validée, puis remplacez progressivement les actions qui nécessitent des schémas, une indexation Spotlight ou un contexte écran.

Pour la première itération, fixez un périmètre mesurable : une ou deux entités principales, trois actions prioritaires, un scénario interapp et une suite de tests négatifs. Vous pourrez ensuite étendre le modèle aux contenus audio, vidéo ou design. Par exemple, une application de montage vidéo peut exposer un projet, une séquence ou un fichier comme entité transférable, tandis qu’un outil de design peut rendre une planche visible et demander à Siri d’ouvrir le composant actuellement sélectionné.

Tester directement sur le Mac principal reste possible, mais ce choix comporte de vrais inconvénients : installation d’un environnement bêta sur le poste de production, conflits entre versions de Xcode, occupation des simulateurs et trousseaux de certificats mélangés avec ceux de la livraison courante. Pour un simple sprint, acheter ou reconfigurer une machine dédiée immobilise aussi du capital et laisse du matériel sous-utilisé après la campagne. Dans ce cas, louer temporairement un Mac physique dédié offre un environnement isolé, une facturation courte et la possibilité de comparer Tokyo et la côte Est américaine avant de généraliser votre stratégie de test. Consultez la page de commande Mac distant, commencez par une location à la journée pour valider votre matrice iOS 27, puis passez à la semaine si la régression Siri AI doit couvrir plusieurs équipes.