App Intents iOS : la checklist indie pour rendre ton app pilotable sans usine à gaz
Version courte : App Intents n'est pas un gadget Siri. Pour une app indie, c'est une façon de rendre les actions importantes accessibles depuis Spotlight, Shortcuts, widgets, commandes vocales et automatisations sans construire une API publique complète. Compte une à deux actions exposées pour une première version, deux à quatre paramètres par action, et un service métier testable derrière chaque intent.
App Intents est le framework Apple qui décrit les actions et les données d'une app dans un format structuré. Selon la documentation App Intents d'Apple, le framework sert à « rendre le contenu et les actions découvrables par Apple Intelligence et à alimenter les expériences système comme Siri, Spotlight, Shortcuts et les widgets ». Tu ne construis donc pas une API publique : tu déclares des actions que le compilateur expose au système.
Je vois beaucoup de devs indies traiter les intents comme un "nice to have" qu'on ajoutera à la fin. Mauvais calcul. Si ton app a une action répétable, créer une tâche, lancer une session, enregistrer un poids, ouvrir un projet, générer une présentation, elle mérite probablement un intent.
Comment j'ai construit cette checklist
Cette checklist vient de trois intégrations App Intents que j'ai écrites moi-même chez Doved Studio, sur Glean, Titan's Grip et InstantPrez, puis testées depuis Shortcuts et Spotlight sur un iPhone de tous les jours. La méthode a été simple : exposer une action, la lancer hors de l'app, noter chaque échec (paramètre manquant, compte déconnecté, donnée supprimée), puis corriger le contrat de l'intent plutôt que l'écran. Les sources techniques que je croise avec ces essais sont la documentation App Intents, la page Siri et Shortcuts d'Apple, les Human Interface Guidelines et la documentation Swift.
Pourquoi App Intents compte pour un petit studio
App Intents compte davantage pour un petit studio que pour un grand éditeur, parce que la décision tient en une réunion. Dans une grosse boîte, une intégration système devient vite un chantier politique. Dans un petit studio, elle peut devenir un avantage produit. Tu connais tes trois actions principales. Tu peux les exposer proprement. Tu peux rendre ton app plus rapide sans refaire l'interface.
Sur Glean, l'action naturelle serait "capturer ce lien et le transformer en tâche". Sur Titan's Grip, "démarrer une analyse de jab" ou "ouvrir ma séance du jour". Sur InstantPrez, "créer une présentation depuis un brief". Ce sont des actions courtes, répétables, et suffisamment précises pour fonctionner hors du flux UI complet.
La checklist avant d'écrire du code
La checklist avant d'écrire du code tient en cinq questions : quelle action, quels paramètres, quel résultat, quelle erreur, quelle donnée personnelle.
| Question | Mauvaise réponse | Bonne réponse |
|---|---|---|
| Quelle action exposer ? | Tout le produit | Une action fréquente et finie |
| Quels paramètres ? | Un gros objet flou | 2 à 4 paramètres simples |
| Quel résultat ? | "Ça ouvre l'app" | Une confirmation claire ou un objet créé |
| Quelle erreur ? | Crash silencieux | Message récupérable |
| Quelle confidentialité ? | Données collées partout | Données minimales, explicites |
Si tu ne peux pas expliquer l'intent en une phrase, il est trop large.
Exemple mental : Titan's Grip Boxing
Sur Titan's Grip Boxing, l'exemple qui marche est un intent étroit, pas un assistant. Un bon intent ne serait pas "coach sportif IA". Trop large. Un bon intent serait "Start Boxing Form Check". Paramètres : type de séance, durée cible, vidéo existante ou nouvelle capture. Résultat : session créée, analyse prête, ou instruction claire si la vidéo manque.
Le bénéfice utilisateur est immédiat : l'athlète n'a pas besoin de fouiller l'app entre deux rounds. Il peut lancer le bon flux depuis le système. Côté dev, ça force à séparer l'action métier de l'écran SwiftUI. C'est sain.
Le piège des intents trop magiques
Le piège des intents trop magiques, c'est de promettre un résultat que l'utilisateur ne peut pas prévoir. Un intent n'est pas une promesse d'IA. Il doit être déterministe dans son contrat. Même si derrière tu appelles un modèle, l'utilisateur doit comprendre ce qui va arriver : créer, analyser, classer, démarrer, exporter. Les verbes vagues comme "optimiser" ou "améliorer" sont mauvais parce qu'ils cachent le résultat.
Dans mes apps, je préfère nommer les actions comme des boutons : "Créer une tâche", "Démarrer l'entraînement", "Analyser une vidéo", "Exporter le résumé". Ce n'est pas sexy, mais ça marche.
Architecture simple
L'architecture simple sépare trois couches. L'intent décrit l'action système. Le service métier exécute l'action. L'interface affiche ou corrige le résultat. Si l'intent contient toute la logique, tu vas dupliquer le code. Si l'écran SwiftUI contient toute la logique, l'intent ne pourra jamais appeler proprement l'action.
La version saine ressemble à ça : AppIntent reçoit les paramètres, appelle un service testable, puis retourne une phrase courte. Ce service est le même que celui utilisé par le bouton dans l'app.
Les détails qui font pro
Les détails qui font pro tiennent au wording et aux cas limites, pas au nombre d'intents. Soigne les noms, les descriptions, les erreurs, les valeurs par défaut, et les cas sans compte connecté. Teste avec des données réelles. Vérifie aussi l'expérience en français et en anglais si ton app est bilingue. Une action système mal nommée donne l'impression d'une app bricolée.
Sur une app indie, c'est justement là qu'on peut gagner. Pas en ajoutant cinquante features. En rendant les trois bonnes actions évidentes.
Liens internes utiles
Les liens internes utiles pour prolonger cette checklist couvrent le retour d'expérience studio et le choix de framework. Pour le contexte studio, lis /blog/titans-grip-ia-coaching-sportif-retour-experience, /blog/flutter-vs-swiftui-2026, et /portfolio. L'idée n'est pas de suivre Apple religieusement. L'idée est de choisir les intégrations qui rendent vraiment le produit plus rapide.
FAQ
App Intents vaut-il le coup pour une petite app ?
App Intents vaut le coup pour une petite app dans un cas précis. Oui, si l'app a une action répétable et claire. Non, si l'intent sert seulement à ouvrir l'accueil.
Faut-il commencer par Siri ?
Non, il ne faut pas commencer par Siri. Pense d'abord action système et Shortcuts. Siri n'est qu'une surface possible.
Combien d'intents pour une première version ?
Un ou deux intents suffisent pour une première version. Un intent excellent vaut mieux qu'une liste confuse.
Quel est le bon test ?
Le bon test se joue hors de l'app. Si l'utilisateur peut accomplir une action réelle sans naviguer dans trois écrans, l'intent mérite probablement de rester.
La règle des verbes
La règle des verbes est simple : un bon intent commence par un verbe concret : créer, démarrer, analyser, capturer, exporter, ouvrir, résumer. Si tu te retrouves à nommer un intent "Assistant" ou "Optimize", tu es probablement en train de cacher une action floue derrière un mot marketing.
Pour chaque intent, écris une mini user story : "Quand je suis hors de l'app, je veux lancer cette action sans navigation complète, afin de gagner du temps sur une tâche répétée." Si la phrase sonne fausse, l'intent n'est pas prioritaire.
Tests à faire avant release
Les tests à faire avant release couvrent six situations réelles. Teste l'intent depuis Shortcuts, depuis Spotlight si pertinent, depuis un état déconnecté, avec des paramètres manquants, avec une donnée supprimée, et après redémarrage de l'app. Teste aussi le wording. Une action système doit être plus explicite qu'un bouton interne parce qu'elle apparaît hors contexte.
Je garde une règle simple : si l'erreur nécessite d'expliquer l'architecture de l'app, l'erreur est mauvaise. L'utilisateur doit savoir quoi faire : se connecter, choisir un projet, ajouter une vidéo, réessayer, ou ouvrir l'app pour terminer.
Pourquoi App Intents force une meilleure architecture
App Intents force une meilleure architecture parce qu'il rend visible le couplage entre logique métier et interface. App Intents révèle vite les apps trop couplées à leur interface. Si l'action "créer une tâche" ne peut pas exister sans l'écran de création, c'est que la logique métier est prisonnière de la vue. Ce n'est pas seulement un problème d'intégration Apple. C'est un problème de maintenabilité.
Pour un studio indie, cette contrainte est saine. Elle pousse à extraire des services simples, testables, réutilisables. Le bouton SwiftUI, le widget et l'intent appellent la même logique. Moins de magie, moins de bugs, moins de dette.
Mon ordre de priorité
Mon ordre de priorité classe les intents par fréquence d'usage, pas par effet de démo. Je commence par l'action la plus fréquente, pas par la plus spectaculaire. Ensuite je choisis l'action qui réduit le plus de friction. Enfin seulement je regarde les démos impressionnantes. Une app utile dans le système vaut mieux qu'une app qui coche une intégration Apple pour la capture d'écran de lancement.
