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.
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.
Sources vérifiées
- Apple Developer, App Intents
- Apple Developer, Siri and Shortcuts
- Apple Human Interface Guidelines
- Swift documentation
Pourquoi ça compte pour un petit studio
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
| 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
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
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
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
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
Pour le contexte studio, lis le retour Titan's Grip, la réflexion Flutter vs SwiftUI, et le portfolio Doved Studio. 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 ?
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. 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. Un intent excellent vaut mieux qu'une liste confuse.
Quel est le bon test ?
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
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
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 ça force une meilleure architecture
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é
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.
