Si une automatisation déclenchée par un commentaire signale une activité status: "sent" mais que la personne qui a commenté indique n’avoir jamais reçu le DM, il s’agit presque toujours des paramètres de confidentialité Instagram du destinataire — pas d’un bug dans votre automatisation ou dans Ayrshare.
sent signifie qu’Instagram a accepté le message, pas qu’il a été livré. Instagram n’expose la livraison des messages sur aucune surface d’API. Ayrshare marque une action send_dm sent à l’instant où Instagram l’accepte ; le fait qu’il atteigne effectivement le destinataire est décidé par des paramètres qu’Ayrshare ne peut ni lire ni modifier.
Le paramètre « Message requests » du destinataire décide de la livraison
Chaque utilisateur Instagram contrôle qui peut lui envoyer une demande de message dans Settings and activity → Messages and story replies → Message requests. Les options sont grosso modo « Tout le monde », « Vos abonnés » et « Personne ».
Lorsque votre automatisation envoie un DM à quelqu’un qui a restreint les demandes de message, Meta accepte la demande, renvoie une réponse de succès avec un ID de message, puis supprime silencieusement le message. Il n’y a pas d’erreur, pas de webhook d’échec, pas de signal de livraison/lecture — la suppression est invisible à chaque couche d’API. Meta sait que le message n’est pas livrable (l’interface de sa propre application affiche « This account can’t receive your message because they don’t allow new message requests from everyone »), mais il ne l’expose pas sur l’API.
Une conversation existante prime sur le paramètre
Si l’expéditeur et le destinataire ont déjà un fil de messages (par exemple, le destinataire a précédemment envoyé un DM au compte), cette conversation existante prime sur le paramètre Message requests et le DM d’automatisation est livré dans le fil existant plutôt que sous forme de nouvelle demande. C’est pourquoi la même automatisation peut atteindre certains commentateurs et pas d’autres, et pourquoi un destinataire qui envoie un message au compte en premier recevra ensuite de manière fiable les DM d’automatisation.
- La ligne d’activité affiche
status: “sent” sans errorDetails. - Le destinataire indique n’avoir aucun DM (et il ne se trouve pas non plus dans son dossier des demandes de message).
- C’est intermittent selon les destinataires — certains reçoivent le DM, d’autres non — sans aucun schéma dans votre configuration.
C’est un résultat de livraison, pas un état d’échec, il n’apparaîtra donc jamais comme failed. Une ligne failed signifie qu’Instagram a rejeté l’envoi et que la raison figure dans actionResults[].errorDetails — c’est une situation différente (voir codes d’erreur).
Ce que vous pouvez faire
Il n’existe aucune solution de contournement programmatique — aucune API, portée ou forme d’envoi ne peut passer outre le paramètre Message requests d’un destinataire. Ce que vous pouvez faire :
- Posez les attentes dès le départ : un DM déclenché par un commentaire n’atteint que les personnes dont les paramètres Instagram autorisent les demandes de message, ou qui ont déjà une conversation avec votre compte.
- Encouragez les commentateurs à envoyer un DM à votre compte (ou à activer les demandes de message) s’ils souhaitent le suivi — un message entrant ouvre le fil de manière permanente.
- Envisagez une réponse publique au commentaire comme chemin de repli pour atteindre tout le monde.
Les automatisations déclenchées par un commentaire livrent le DM via les private replies d’Instagram, ancrées au commentaire lui-même. C’est ce qui permet à l’automatisation d’envoyer un message à un commentateur à qui vous n’avez jamais envoyé de message auparavant. Les mécanismes — et leurs limites — méritent d’être connus :
- Fenêtre de 7 jours ancrée au commentaire. La réponse doit être envoyée dans les 7 jours suivant le commentaire. Passé ce délai, la fenêtre se ferme et l’envoi échoue avec
code: 484. - Une seule réponse par commentaire, à vie. Instagram n’autorise qu’une seule private reply par commentaire. Une seconde tentative échoue avec
code: 484 — Instagram signale « déjà répondu » via la même erreur partagée qu’il utilise pour une fenêtre fermée, donc vérifiez errorDetails pour savoir de quel cas il s’agit. - Arrive sous forme de demande de message. Même une private reply livrée avec succès atterrit dans le dossier des demandes de message du destinataire et doit être acceptée — sauf si une conversation existe déjà.
- La livraison dépend toujours des paramètres du destinataire. Les private replies suppriment l’exigence « doit avoir envoyé un message d’abord », mais elles ne surpassent pas le paramètre Message requests du destinataire, qui est la limitation décrite ci-dessus.
Ressources associées
