Un rapport qui se lance tout seul, à l'heure que vous choisissez.
Rédigez un prompt réutilisable, choisissez les bases et connecteurs qu'il peut consulter, fixez un planning (ou déclenchez-le à la demande), et laissez Astrolabe livrer le résultat par e-mail, Slack ou webhook. Une requête, un résultat, une livraison : pas un agent qui erre entre deux exécutions.
Ni un cron brut, ni un agent autonome
Le juste milieu pour vos rapports et alertes récurrents
Un prompt, des variables
Rédigez le prompt une fois, avec des variables ${variable} remplies à chaque exécution (par vous, ou par un appel API). Des valeurs système sont disponibles d'office : date du jour, nom de la tâche.
Planning ou à la demande
Manuel, quotidien, jours ouvrés, hebdomadaire, ou déclenché par API. Fréquence minimale d'une heure, un seul run à la fois par tâche.
Trois sorties, indépendantes
E-mail, Slack (un canal, ou en message privé à une personne) et webhook signé pour vos automatisations. Un échec sur l'une n'empêche pas les autres.
Historique complet
Chaque exécution est consignée avec son résultat, déchiffré à la demande. De quoi vérifier ce qui a été envoyé, et à qui.
Jamais de clé mise de côté
Chaque run réutilise la clé et le périmètre du moment de la personne qui a créé la tâche. Un accès révoqué se traduit par un échec propre, pas par une fuite.
Pas de dérive
Une tâche, une requête /v1/chat/completions par exécution. Pas de chaînage tâche après tâche, pas de mémoire cachée entre deux runs.
En détail
Du prompt à la livraison, sous votre contrôle
Un prompt, pas un script
Déclarez les variables dont votre prompt a besoin (avec valeurs par défaut si besoin), et les ressources qu'il peut consulter : bases de connaissance, connecteurs, recherche web, exécution de code. La tâche ne voit que ce que vous lui donnez.
📝 Variables ${var} · valeurs système (date, nom de la tâche) · ressources déclarées explicitement.
Manuel, planifié, ou piloté par API
Choisissez un préréglage (quotidien, jours ouvrés, hebdomadaire) traduit en planning, ou déclenchez la tâche vous-même. Un seul run à la fois par tâche : le suivant est proprement ignoré si le précédent tourne encore, sans empiler les exécutions.
Livré là où votre équipe travaille
E-mail (mise en forme automatique du texte du modèle), Slack (dans un canal, ou en message privé à une personne en indiquant simplement son adresse) et webhook (pour brancher Make ou n8n en aval). Chaque destination est livrée indépendamment : un canal Slack indisponible n'empêche pas l'e-mail de partir.
✉️ Resend souverain · 💬 canal ou DM Slack · 🔗 webhook signé HMAC, retries sur erreur transitoire.
Un texte à lire, ou un objet à consommer
Sortie texte pour un rapport lu par une personne, ou JSON structuré (avec le schéma de votre choix) quand la tâche alimente un autre outil. Le webhook reçoit alors l'objet déjà parsé, prêt à l'emploi.
Rien n'est stocké à part
Aucune clé sk- n'est mise de côté pour la tâche. Chaque exécution re-résout la clé managée et le périmètre actuel de la personne qui l'a créée. Si son accès est révoqué ou qu'une base a été retirée, le run échoue proprement (ou se réduit à ce qui reste), jamais de réponse inventée à la place d'une donnée manquante.
🔐 Clé re-résolue à chaque run · garde-fou anti-réponse « de mémoire » · réservé aux organisations, « chacun les siennes ».
Pilotable sans le portail
Listez, modifiez, déclenchez et consultez l'historique de vos tâches par API (/v1/tasks), exposé aussi dans Make et Zapier. La création reste au portail, le pilotage courant peut se faire depuis vos automatisations.
Une tâche déclenche une seule requête /v1/chat/completions par exécution : pas de chaînage, pas d'écriture automatique dans une base. Voir la documentation →
Vos rapports, sans y penser.
Écrivez le prompt une fois, choisissez le planning et la livraison, et laissez Astrolabe faire le reste, à l'heure que vous avez fixée.