Notifications push pour les workflows de codage IA : concevoir une livraison fiable

Claude Code peut s'executer pendant des minutes ou des heures sur une tache complexe. Sans notifications, vous surveillez le terminal en permanence ou vous revenez periodiquement en esperant n'avoir rien manque d'important. Aucune de ces approches ne respecte votre temps.

Les notifications push sont ce qui fait de Tactic Remote un outil de workflow plutot qu'un simple visualiseur distant. Cet article explique comment nous avons construit le systeme de notifications, l'integration avec les hooks de Claude Code, l'ingenierie de fiabilite de la livraison et les schemas d'utilisation que nous avons observes chez de vrais developpeurs.

L'idee centrale

La valeur des notifications push dans Tactic Remote n'est pas "votre telephone vibre". C'est que les notifications changent quand et comment vous interagissez avec votre agent de codage IA. Au lieu d'une surveillance synchrone du terminal, vous obtenez une gestion asynchrone des taches :

1. Lancez une tache Claude Code depuis votre Mac (ou depuis l'app iPhone).
2. Eloignez-vous. Faites un cafe. Participez a une reunion. Rentrez chez vous.
3. Votre telephone vous notifie quand la tache se termine, rencontre une erreur ou necessite votre approbation.
4. Vous examinez et repondez en quelques secondes, puis reprenez ce que vous faisiez.

Nous appelons cela le workflow "verifiez votre telephone, pas votre bureau". C'est le meme modele mental que les notifications CI/CD — vous ne surveillez pas votre pipeline de build, vous attendez qu'il vous communique le resultat.

Integration des hooks Claude Code

Le systeme de notifications est alimente par le mecanisme de hooks de Claude Code. Les hooks sont des scripts configurables par l'utilisateur que Claude Code execute a des points definis du cycle de vie. L'app compagnon Mac de Tactic Remote enregistre des hooks pour trois types d'evenements :

Completion de tache — Se declenche quand Claude Code termine le traitement d'une requete. Le hook capture le statut de sortie, un resume des modifications effectuees et les dernieres lignes de sortie du terminal.

Approbation requise — Se declenche quand Claude Code rencontre une operation necessitant une confirmation humaine (ecritures de fichiers hors du repertoire du projet, commandes shell, requetes reseau, etc.). Le hook capture la description de l'operation en attente et un identifiant d'approbation unique.

Erreur — Se declenche quand Claude Code rencontre une erreur fatale, une defaillance d'outil ou un timeout d'API. Le hook capture le message d'erreur et le contexte pertinent.

Chaque invocation de hook envoie un payload structure au serveur compagnon Mac, qui determine le routage de la notification, construit le payload APNs (Apple Push Notification service) et le distribue via notre relais de notifications.

Types de notifications en pratique

Chaque type de notification est concu pour un schema d'interaction specifique :

Les notifications de completion de tache incluent le resume de la tache et un indicateur de statut (succes ou completion partielle). Toucher la notification ouvre l'app Tactic Remote directement sur la vue terminal de la session completee pour que vous puissiez examiner la sortie.

Les notifications d'approbation ont la priorite la plus elevee. Elles incluent la description de l'operation ("Claude veut executer rm -rf build/ dans le repertoire du projet") et presentent des actions Approuver/Rejeter directement sur la banniere de notification. Sur iPhone, vous pouvez repondre a une approbation sans ouvrir l'app — appuyez longuement sur la notification pour voir les actions en ligne. Notre telemetrie montre que 62% des approbations sont gerees via les actions de notification sans ouvrir completement l'app.

Les notifications d'erreur incluent la categorie d'erreur et un message tronque. Elles sont actionnables — toucher ouvre la vue de session ou vous pouvez examiner le contexte d'erreur complet et decider de relancer ou modifier la tache.

Fiabilite de la livraison

APNs ne garantit pas la livraison des notifications push. La documentation d'Apple indique que les notifications sont au "meilleur effort" et peuvent etre perdues en raison de la gestion energetique de l'appareil, des conditions reseau ou des limites de debit. Pour un outil de developpement ou une notification d'approbation manquee signifie une tache bloquee, le "meilleur effort" est insuffisant.

Nous superposons plusieurs mecanismes de fiabilite sur APNs :

Suivi d'etat cote serveur. Le serveur compagnon Mac maintient un registre de livraison pour chaque notification. Chaque notification a un identifiant unique, un horodatage et un etat de livraison (en attente, envoyee, accusee, expiree).

Accusation de reception cote client. Quand l'app iPhone recoit et affiche une notification, elle envoie un accuse de reception au serveur compagnon Mac. Si aucun accuse n'arrive dans les 30 secondes, le serveur retransmet.

Retransmission avec backoff exponentiel. Les notifications non accusees sont retentees a des intervalles de 30s, 60s et 120s. Apres trois echecs, la notification est marquee comme potentiellement non livrable et signalee dans l'interface de statut du compagnon Mac.

Synchronisation dans l'app. Quand l'app iPhone s'ouvre (ou revient de l'arriere-plan), elle interroge le compagnon Mac pour toute notification non accusee et les affiche dans le centre de notifications. Cela rattrape toute notification qu'APNs a completement perdue.

Deduplication. Avec la retransmission vient le risque de livraison en double. Chaque notification porte un identifiant unique que le client iPhone suit. Les doublons sont silencieusement rejetes — vous ne voyez jamais la meme demande d'approbation deux fois.

En pratique, notre taux de succes de livraison (notification envoyee jusqu'a notification accusee) est de 97,3% en 10 secondes et de 99,6% en 60 secondes sur notre base d'utilisateurs beta.

Details de la deduplication des notifications

La deduplication merite une attention particuliere car elle affecte la confiance des utilisateurs. Si un developpeur voit la meme notification "approuver l'ecriture de fichier" deux fois, il se demande s'il l'a deja approuvee. S'il voit une notification d'approbation pour une operation qu'il a deja approuvee, il se demande si son approbation a ete recue.

Notre deduplication fonctionne a deux niveaux :

Niveau transport. Chaque notification a un UUID qui persiste a travers les retransmissions. Le client iPhone maintient une fenetre glissante de 500 UUIDs recemment vus. Toute notification avec un UUID deja vu est rejetee avant affichage.

Niveau semantique. Pour les notifications d'approbation specifiquement, le client verifie si l'identifiant d'approbation a deja fait l'objet d'une action. Si vous avez approuve une operation via la premiere livraison de notification et qu'une retransmission arrive, la retransmission est supprimee meme si son UUID de transport differe (ce qui peut se produire si le serveur a genere un nouveau payload push pour la tentative).

Comment les developpeurs utilisent reellement les notifications

Apres quatre mois de donnees beta, des schemas clairs ont emerge :

Les heures de pointe des notifications sont 9h-11h et 14h-16h dans le fuseau horaire local de l'utilisateur — correspondant au debut des sessions de codage et aux blocs de productivite de l'apres-midi.

Le temps de reponse moyen aux notifications d'approbation est de 12 secondes. Le P95 est de 47 secondes. Cela signifie que meme dans la queue de distribution, les approbations humaines ajoutent moins d'une minute a l'execution de la tache — un faible prix pour la garantie de securite.

Le workflow le plus courant base sur les notifications : Demarrer une tache de refactoring en plusieurs etapes, quitter le bureau pour une reunion, approuver 2-3 operations sur des fichiers pendant la reunion via les actions de notification, et revenir pour trouver la tache terminee.

Volume de notifications : L'utilisateur actif median recoit 8 notifications par jour. Les utilisateurs avances (P95) en recoivent environ 30. Nous n'avons pas constate de fatigue des notifications dans nos enquetes — probablement parce que chaque notification represente un evenement actionnable et non une mise a jour de statut.

Schemas de mise en sourdine : 15% des utilisateurs configurent des regles de "mode concentration" qui regroupent les notifications non liees aux approbations pendant certaines heures. Les notifications d'approbation sont toujours livrees immediatement quel que soit le mode concentration, car une approbation bloquee bloque l'ensemble de la tache.

Prochaines etapes

Nous travaillons sur plusieurs ameliorations des notifications :

• Notifications riches avec apercu du code — Des notifications d'approbation qui affichent un apercu du diff directement sur la notification, pour que vous puissiez prendre des decisions eclairees d'approbation/rejet sans ouvrir l'app.
• Regroupement des notifications — Regroupement des completions rapides de taches (courantes dans les workflows multi-sessions) en une seule notification resumee.
• Sons de notification personnalises — Des signaux audio distincts pour les completions, approbations et erreurs, pour que vous puissiez trier par le son sans regarder votre telephone.

Pour les options de configuration des notifications, consultez le guide de Configuration des Notifications. Pour la reference des hooks Claude Code qui alimente ce systeme, consultez Integration des Hooks.