Développer des aApps

Si vous envisagez de créer ou de personnaliser des aApps, suivez cette approche :

1. Définissez d’abord les capacités, puis concevez l’interface

   1. Commencez par définir le problème, les utilisateurs cibles et le résultat attendu.

   2. Concevez les actions sémantiques (destinées à être invoquées par l’Agent) avant de créer l’interface.

   3. Évitez de créer trop tôt un trop grand nombre de pages et de boutons : cela accroît la complexité et réduit la composabilité.

2. Créez des interfaces adaptées aux Agents

   1. Utilisez des noms clairs et axés sur l’action.

   2. Utilisez des paramètres concis et cohérents.

   3. Concevez les éléments pour qu’ils soient composables et que les workflows en plusieurs étapes puissent s’enchaîner de manière fiable.

3. Commencez par créer une boucle minimale viable

   Commencez par donner la priorité à cette boucle de base :

   Demande de l’utilisateur → L’Agent appelle une aApp → L’aApp renvoie un résultat exploitable

   Une fois cette boucle stable, ajoutez des capacités avancées comme les abonnements, l’automatisation et une interface plus riche.

4. Séparez la récupération des réponses

   1. Utilisez des capacités axées sur la récupération lorsque vous avez besoin de candidats structurés (identifiants, métadonnées, résultats traitables par machine).

   2. Utilisez des capacités axées sur les réponses lorsque vous avez besoin de réponses directement destinées aux utilisateurs.

   3. Cette séparation améliore la fiabilité, l’interprétabilité et les performances.

5. Concevez l’automatisation des événements comme un pipeline complet

   Un abonnement ne se résume pas à un déclencheur. Un flux robuste doit inclure :

   Condition de déclenchement → Enrichissement du contexte → Analyse/traitement → Écriture en retour/retour d’information

   Ainsi, l’automatisation apporte systématiquement de la valeur au lieu de se contenter de « déclencher des événements ».

Une conception adaptée aux développeurs dans remio

1. Isolation des environnements DEV / PROD

   1. DEV est destiné au développement, au débogage et aux tests.

   2. PROD est destiné à une utilisation quotidienne stable.

   3. Le code et les données sont isolés, afin que les tests n’affectent pas l’utilisation en production.

2. Changement visuel d’environnement

   1. Le statut DEV/PROD est visible dans la navigation et se change facilement.

   2. Cela permet un développement itératif et sûr.

3. Deux points d’entrée : Skill Market + Skill Studio

   1. Skill Market: découvrez, installez et gérez les skills disponibles.

   2. Skill Studio: clonez, modifiez et publiez des skills à des fins de test.

   3. Les fonctions « utiliser » et « créer » sont clairement séparées, ce qui facilite l’adoption.

4. Intégration MCP : accès facile + grande flexibilité

   1. Prend en charge une prise en main rapide avec OAuth et une configuration manuelle (stdio / streamable-http).

   2. Convient aussi bien à une adoption rapide qu’aux scénarios d’intégration avancés.

Conseils pour les développeurs

• Effectuez une validation approfondie dans DEV avant de passer à PROD.

• Ajoutez une seule dépendance externe à la fois (par exemple, un serveur MCP) afin de faciliter le dépannage.

• Réutilisez d’abord les Skills/aApps existants, puis personnalisez-les progressivement.

• Pour chaque flux automatisé, prévoyez une solution de repli en cas d’échec et un retour visible pour l’utilisateur.