# Codex peut-il rédiger un avis de panne Facebook à partir des notes d'incident ? > Source: https://tareno.co/fr/agents/codex/facebook > Language: fr > Codex transforme les notes confirmées en avis de panne Facebook et en brouillon de suivi à vérifier et approuver dans Tareno. > Last reviewed: 2026-10-24 ## Codex peut-il écrire un avis pour notre page Facebook à partir des notes d'incident ? Oui. Codex lit les notes et le code du service concerné, rédige un avis et un brouillon de suivi en langage simple, puis les enregistre via Tareno. Il ne doit pas inventer de cause ni de délai de résolution : l'équipe technique doit les confirmer. Rien n'est publié avant votre approbation. Lorsqu'un service de réservation ou de paiement tombe en panne, les clients peuvent chercher des informations sur la page Facebook de l'entreprise et y laisser des commentaires. Un avis utile doit être rapide, précis et honnête, même pendant que l'équipe technique cherche encore une solution. Codex peut lire les notes d'incident et le code concerné, puis préparer un texte compréhensible. Tareno enregistre le brouillon pour la page. Suivons le cas d'une billetterie pour distinguer les faits confirmés des hypothèses et comprendre pourquoi une personne responsable doit vérifier le texte avant publication. ## Exemple : une billetterie signale une panne de paiement Dans une billetterie, le paiement par carte échoue lors de l'achat, tandis que les autres moyens fonctionnent. La personne d'astreinte fournit les notes d'incident à Codex et lui indique le module de paiement. Codex lit les notes et le chemin de code concerné pour aider à délimiter l'impact, que l'équipe technique doit confirmer. Il rédige un avis d'environ 60 mots : le moyen touché, une solution de remplacement et la promesse d'un suivi, sans inventer d'heure de réparation. Il enregistre l'avis avec `create_drafts` et prépare un second brouillon non programmé pour la résolution. La personne vérifie les deux textes auprès du canal d'incident et demande la publication du premier dans Tareno. ## Du brief au brouillon vérifié 1. **Fournissez les notes d'incident.** Transmettez à Codex l'état actuel des notes en distinguant les faits confirmés des hypothèses ouvertes. Ne partagez que les informations nécessaires à l'avis : une hypothèse ne doit pas devenir une affirmation publique. 2. **Indiquez le code concerné.** Désignez le module touché. Codex peut examiner les parcours qui partagent le chemin de code, par exemple les cartes mais pas les factures. L'équipe technique doit confirmer l'impact réel avant sa communication. 3. **Préparez l'avis et le suivi.** Demandez un avis bref avec l'impact confirmé, les alternatives possibles et l'annonce d'une mise à jour. Le second brouillon destiné à la résolution reste sans faits non confirmés et sans créneau programmé. 4. **Retirez causes et délais non confirmés.** Vérifiez si le brouillon mentionne une cause ou un délai de réparation que l'équipe technique n'a pas confirmé et supprimez-les. Annoncez plutôt une mise à jour sans inventer d'heure de résolution. 5. **Enregistrez les deux brouillons.** Codex vérifie la page Facebook avec `list_accounts` et enregistre les textes via `create_drafts`. La publication se fait en tant que page, au nom de l'entreprise. Lisez les deux brouillons avant de les approuver. 6. **Demandez et approuvez le premier avis.** Demandez le premier créneau autorisé. Selon la documentation Meta, les posts programmés par API nécessitent au moins dix minutes d'avance. La demande reste en attente jusqu'à votre approbation dans le tableau de bord Tareno. ## Six demandes à copier ### Séparer faits et hypothèses ```text Lis les notes d'incident ci-dessous et le module [payments/card]. Liste les faits confirmés, les hypothèses et les parcours clients qui partagent le chemin de code concerné. Signale ce que l'équipe technique doit encore confirmer. Ne rédige aucun avis avant que j'aie vérifié la liste : [notes]. ``` ### Rédiger l'avis ```text Rédige pour notre page Facebook un avis de panne d'environ 60 mots en utilisant uniquement les faits confirmés. Indique le moyen de paiement touché, une alternative confirmée et l'arrivée d'une mise à jour. N'invente ni cause ni délai de réparation et évite les termes techniques. ``` ### Préparer l'annonce de résolution ```text Rédige un second post court pour le moment où le problème sera résolu, avec un emplacement pour l'heure confirmée. N'indique pas de cause tant que je ne te l'ai pas fournie. Enregistre les deux posts comme brouillons Tareno pour notre page Facebook [nom] et renvoie leurs identifiants. ``` ### Demander la publication de l'avis ```text Demande à Tareno de programmer le brouillon [identifiant de l'avis] au premier créneau autorisé et indique-moi l'heure demandée. Renvoie l'identifiant de l'action en attente et rappelle que le post ne sera publié qu'après mon approbation dans le tableau de bord Tareno. ``` ## Réseaux sociaux pris en charge - Selon la documentation Meta, les posts programmés par API nécessitent au moins dix minutes d'avance. Une demande programmée ne produit donc pas un avis instantané : prévoyez ce délai ou utilisez le parcours de publication approuvé. - Tareno peut lire les commentaires Facebook. Après l'avis, Codex peut regrouper les retours, par exemple sur un autre moyen de paiement touché, et les transmettre à l'équipe technique. - Les posts Facebook dans Tareno peuvent contenir un lien avec une carte d'aperçu, utile pour diriger les clients vers la page de statut de l'entreprise. - Selon la documentation Meta, la Pages API publie en tant que page et une application ne peut modifier que les posts qu'elle a créés. Un avis publié directement sur Facebook doit donc être corrigé sur Facebook. ## Résoudre les problèmes - Indiquer une cause trop tôt : une hypothèse non confirmée peut se révéler fausse et provoquer de nouvelles réclamations des clients concernés. - Promettre une heure de réparation : annoncez plutôt une mise à jour ultérieure et respectez cet engagement auprès des clients. - Oublier le délai nécessaire : la demande ne peut pas précéder le créneau autorisé par la plateforme ; prévoyez et approuvez-la rapidement. - Laisser le brouillon de résolution incomplet : gardez l'emplacement visible pour éviter qu'une personne programme par erreur un post contenant des informations non confirmées. - Codex ne peut pas connaître une cause ou un délai de réparation non confirmé par l'équipe technique ; ces informations doivent venir de personnes responsables. - Il ne peut pas répondre aux commentaires des clients : Tareno lit les commentaires Facebook mais ne fournit pas d'outil pour publier une réponse. - Il ne peut pas publier l'avis seul : une demande de créneau ne devient un post qu'après votre approbation dans le tableau de bord Tareno. ## Questions avant la connexion ### Codex peut-il rédiger un avis à partir des notes ? Oui. Il distingue les faits confirmés des hypothèses, peut examiner le code pour repérer les parcours concernés et prépare un avis bref. Une personne responsable vérifie l'impact réel et approuve le post dans Tareno avant publication. ### L'avis peut-il paraître immédiatement ? Selon la documentation Meta, les posts programmés par API doivent être prévus au moins dix minutes à l'avance. Demandez à Tareno le premier créneau autorisé et approuvez la demande dans le tableau de bord, en tenant compte de ce délai plutôt que de supposer une publication immédiate. ### L'avis doit-il mentionner la cause ? Seulement si l'équipe technique l'a confirmée. Codex peut examiner le code, mais une cause encore hypothétique ne doit pas être présentée comme un fait public. Annoncez une mise à jour ultérieure plutôt que de deviner un délai de réparation. ### Codex peut-il lire les commentaires des clients ? Oui. Tareno permet de lire les commentaires Facebook et Codex peut les regrouper, en signalant par exemple un autre moyen de paiement touché. Il ne peut pas publier de réponse par ce parcours ; l'équipe d'assistance s'en charge. ### Est-il sûr de fournir les notes d'incident à Codex ? Ne partagez que ce qui est nécessaire à l'avis. N'incluez pas de secrets, de données clients ni de détails d'accès internes : le contenu de la demande devient une partie de l'historique de conversation et doit être vérifié avant envoi. ### Codex publie-t-il seul sur notre page ? Non. Une demande de programmation devient une action en attente dans Tareno et Facebook ne reçoit le post qu'après votre approbation dans le tableau de bord. `get_action_status` permet ensuite de vérifier l'état de la demande. ## Ressources Tareno associées - [Codex peut-il annoncer une version CLI sur X avec une commande de mise à jour vérifiée ?](https://tareno.co/fr/agents/codex/x.md) - [Codex peut-il expliquer un changement technique aux lecteurs de LinkedIn ?](https://tareno.co/fr/agents/codex/linkedin.md) - [Codex peut-il expliquer un algorithme dans un fil Bluesky avec des résultats vérifiés ?](https://tareno.co/fr/agents/codex/bluesky.md) - [Codex peut-il rédiger un avis de panne Facebook à partir des notes d'incident ?](https://tareno.co/fr/agents/codex/facebook.md) - [Codex peut-il transformer des notes de version en carrousel Instagram ?](https://tareno.co/fr/agents/codex/instagram.md) - [Codex peut-il créer des vidéos TikTok « trouve l’erreur » à partir d’un dépôt ?](https://tareno.co/fr/agents/codex/tiktok.md) - [Codex peut-il écrire un script YouTube Shorts pour expliquer une fonctionnalité d'API ?](https://tareno.co/fr/agents/codex/youtube.md)