Pourquoi le rapport de nuit n'est-il pas parti ?

Le plus souvent parce qu'un script est lancé à heure fixe par le système et que le serveur était en train de redémarrer, ou que le script a échoué sans que personne ne soit alerté. La construction qui règle cela : une tâche planifiée dans une file, une rattrapeuse au démarrage qui reprend les heures manquées, et une alerte si le rapport n'est pas parti à l'heure prévue plus un délai.

Pourquoi les SMS sont-ils partis deux fois ?

Parce que deux serveurs ou deux clics ont lancé le même envoi, ou qu'une reprise a renvoyé des messages déjà partis. La construction : un verrou avec bail dans la base de données pour qu'une tâche ne soit prise qu'une fois, et une clé d'idempotence par message pour qu'un message déjà envoyé ne reparte jamais, même après une reprise.

Qu'est-ce qu'une file de travaux ?

Une table de tâches dans la base de données, avec un état, une priorité, une échéance, une charge, une clé et un bail, et des exécutants qui prennent la tâche suivante, la verrouillent, l'exécutent et notent le résultat. Tout ce qui ne doit pas bloquer l'écran y passe : envois, exports, recalculs, rapports, relances, imports.

Comment réessayer sans aggraver la panne du fournisseur ?

Avec une attente qui double entre les tentatives, tirée au hasard dans une fenêtre pour que mille tâches ne repartent pas à la même seconde, et plafonnée. C'est la recommandation publiée par l'équipe architecture d'Amazon Web Services. Après le dernier essai, la tâche va dans la file des échecs avec une alerte.

Que devient une tâche qui échoue définitivement ?

Elle va dans la file des échecs, avec sa cause, sa charge et son nombre de tentatives, et une alerte part au responsable. Un humain lit cette file chaque matin, relance ou corrige. Elle n'est jamais supprimée en silence.

Combien d'exécutants faut-il ?

Pour la plupart des PME, deux suffisent : un pour les tâches lourdes, une à la fois, et un pour les tâches courtes en parallèle ; on en ajoute quand la file grossit, et c'est un chiffre qu'on mesure plutôt qu'on devine. Où tournent ces exécutants dépend de l'hébergement choisi.

Combien de temps pour mettre cela en place ?

Six semaines dans le calendrier type : une pour l'inventaire des tâches, une pour la file et les exécutants, une pour les reprises et la file des échecs, une pour la planification, une pour la migration des scripts existants, une pour la mesure. Le délai dépend du nombre de scripts existants et de fournisseurs d'envoi.

« Le rapport de nuit n'est jamais parti, et personne ne l'a su » : ce qu'on construit pour les tâches en arrière-plan d'une application en Algérie en 2027, file de travaux, verrou, reprises, idempotence, planification, file des échecs

Réponse courte. Tout ce qui ne doit pas bloquer l'écran, envois, exports, recalculs, rapports, relances, devient une tâche dans une file de travaux stockée dans la base de données, avec une priorité, une échéance, une charge et une clé d'idempotence. Un exécutant prend la tâche en la verrouillant avec un bail de quelques minutes, qu'il renouvelle tant qu'il avance et qui tombe s'il meurt ; deux exécutants ne prennent jamais la même. Quand la tâche échoue, elle réessaie après une attente qui double, tirée au hasard dans une fenêtre pour que mille tâches ne repartent pas à la même seconde, et plafonnée ; la clé fait que la partie déjà faite ne se refait pas. Après le dernier essai, la tâche va dans une file des échecs avec une alerte, et un humain la lit chaque matin. Les tâches à heure fixe ont une rattrapeuse au démarrage pour les heures manquées, un débit pour les envois, et un journal que le gérant lit à 7 h. Six semaines, dont la première sans code.

Ce guide s'adresse au gérant dont les rappels partent deux fois ou pas du tout, au fondateur installé en France qui attend un rapport de nuit qui n'arrive plus, et au responsable qui a vu un export de la compta planter trois fois de suite. Il ne redit pas quel canal envoyer quel message, décrit dans le guide sur les notifications, ni comment une application de terrain met ses écritures en file sans réseau, décrit dans le guide sur le hors ligne ; il décrit la machine qui, côté serveur, fait tourner tout ce qui n'a pas d'écran, et il prolonge notre page sur l'ingénierie logicielle.

Des tâches en arrière-plan qui tiennent, en cinq couches

Un script lancé par le système à minuit est une couche sur cinq. Les quatre autres sont ce qui fait qu'il réussit, ou qu'on le sache quand il échoue.

Figure 1 · La couche accentuée est celle qui distingue une file de travaux d’un script lancé à minuit : l’échec y est un état prévu, avec une attente, une clé et une sortie. Sans elle, une coupure du fournisseur SMS à 6 h 30 fait perdre les rappels du jour, ou les envoie deux fois.

Demandes. Tout ce qui ne doit pas bloquer l'écran : l'envoi de 1 200 rappels, l'export de 50 000 lignes, le recalcul des stocks, le rapport du lundi, les relances de paiement ; l'écran répond en une seconde en créant une tâche avec une priorité et une échéance, et la tâche fait le travail derrière. File de travaux. Une table de tâches dans la base de données, avec état, priorité, échéance, charge, clé d'idempotence, nombre de tentatives et bail ; la file est sauvegardée avec la base, selon le guide sur les sauvegardes, et visible dans l'application. Exécution. Un exécutant verrouille la tâche avec un bail de quelques minutes, l'exécute avec une durée maximale, renouvelle le bail tant qu'il avance, et le relâche s'il meurt ; deux exécutants ne prennent jamais la même tâche, parce que c'est la base de données qui tient le verrou.

Reprises et échecs. C'est la couche accentuée : un échec déclenche une reprise après une attente qui double, tirée au hasard, plafonnée ; la clé d'idempotence fait que la partie déjà faite ne se refait pas ; après le dernier essai, la tâche va dans la file des échecs et quelqu'un est alerté. Planification et mesure. Les tâches à heure fixe ont une rattrapeuse au démarrage ; les envois ont un débit lissé ; un journal dit ce qui a tourné, un tableau montre les tâches en retard, en échec et en attente, et une alerte part si la file grossit, dans l'esprit de le guide sur la surveillance.

Ce qu'une tâche doit savoir faire

Six propriétés d'une tâche bien construite, et la troisième est celle qui évite le pire.

Figure 2 · Le troisième point est accentué parce que c’est celui qui évite le pire : deux exécutants qui prennent la même tâche et envoient deux fois. Le premier point est celui qui rend tous les autres faciles : une tâche de cent envois reprend en dix secondes, une tâche de mille deux cents reprend en deux minutes et refait ce qui était fait.

Être petite : 1 200 envois, ce sont douze tâches de cent ; un export, ce sont des lots ; une tâche courte reprend vite et refait peu. Porter sa clé : la même tâche prise deux fois ne fait le travail qu'une fois, et un message déjà envoyé ne repart pas, selon la mécanique décrite dans le guide sur le hors ligne. Se verrouiller : un bail renouvelé, relâché si l'exécutant meurt ; c'est ce qui évite les deux rappels par client. Échouer proprement : la cause est écrite, et l'attente avant la prochaine tentative double, avec du hasard et un plafond.

Respecter un débit : un message par seconde vers le fournisseur de messages, neuf lots pour un export, jamais de rafale, parce que le fournisseur coupe le compte qui envoie 1 200 messages en dix secondes ; le détail des canaux est dans le guide sur l'agent WhatsApp. Laisser une trace : début, fin, résultat, tentatives, lisibles par le gérant, pas seulement par le développeur.

Une tâche, de la file à la réussite ou à la file des échecs

La figure suit une tâche « envoyer 1 200 rappels WhatsApp » pendant que le fournisseur de messages est indisponible.

Figure 3 · Une tâche « envoyer 1 200 rappels » échoue trois fois parce que le fournisseur est indisponible, puis réussit à la quatrième tentative ; les attentes doublent et sont tirées au hasard dans une fenêtre, pour que mille tâches en échec ne repartent pas toutes à la même seconde, et sont plafonnées. Les 380 messages partis à la première tentative ne repartent pas, grâce à la clé d’idempotence. Après le dernier essai, la tâche irait dans la file des échecs avec une alerte. Les durées sont un exemple construit.

La tâche est prise et verrouillée ; la première tentative échoue parce que le fournisseur répond indisponible, mais 380 messages étaient déjà partis. La deuxième tentative attend trente secondes, plus ou moins dix tirées au hasard ; la troisième deux minutes, plus ou moins trente secondes ; la quatrième huit minutes, plus ou moins deux, et réussit : 1 200 envoyés, zéro doublon, parce que la clé d'idempotence, rappel plus rendez-vous plus date, fait sauter les 380 déjà partis. Si une cinquième tentative avait été nécessaire, l'attente aurait été plafonnée à trente minutes, et au-delà la tâche serait allée dans la file des échecs avec une alerte au responsable.

Le hasard dans l'attente n'est pas un détail : quand un fournisseur tombe, mille tâches échouent à la même seconde, et sans hasard elles réessaient toutes à la même seconde, ce qui le fait retomber. L'équipe architecture d'Amazon Web Services a publié une recommandation sur ce point : une attente exponentielle plafonnée, avec du hasard, qui étale les reprises et réduit nettement le nombre d'appels. La file des échecs est lue chaque matin par un humain, qui relance ou corrige ; elle n'est jamais vidée en silence. Les durées de la figure sont un exemple construit.

«Une tâche qui échoue n'est ni perdue ni rejouée à l'infini : elle réessaie à des intervalles qui doublent, tirés au hasard, plafonnés, et finit dans une file qu'un humain lit.»

Six situations réelles, et ce que l'application fait

Les six situations qu'on retrouve dans presque toutes les applications qu'on reprend, et la construction qui les règle.

Figure 4 · Les deux premières lignes se règlent par la rattrapeuse et par le verrou ; les deux suivantes par les lots et les reprises ; les deux dernières par le débit et la durée maximale. Aucune ne se règle par un développeur qui se lève la nuit.

Les deux premières lignes se règlent par la rattrapeuse au démarrage et par le verrou avec bail ; la deuxième est la plus coûteuse, parce que deux rappels par client sont vus par 1 200 clients. Les deux suivantes se règlent par les lots et les reprises : un export en arrière-plan par lots dépose un fichier et envoie un lien, et une panne du fournisseur devient un retard de dix minutes au lieu d'une perte. Les deux dernières se règlent par le débit lissé et la durée maximale avec bail expiré. Aucune ne se règle par un développeur qui se lève la nuit pour relancer un script.

La nuit d'un serveur, sur deux exécutants

La figure montre ce qui tourne entre 22 h et 7 h sur un serveur d'une PME, sur deux exécutants, et trois choses qui se seraient mal passées sans la file.

Figure 5 · La nuit d’un serveur, sur deux exécutants : la sauvegarde tient le verrou « base » et le nettoyage attend ; l’export comptable part par lots ; le rapport du lundi est manqué par un redémarrage à 2 h 04 et repris par la rattrapeuse à 2 h 15 ; les 1 200 rappels de rendez-vous partent à 6 h 30 en lots de cent, un message par seconde ; le rapport part à 7 h avec ce qui a tourné. Les horaires sont un exemple construit.

L'exécutant A fait les tâches lourdes une à la fois : la sauvegarde de la base à 22 h, qui tient le verrou « base » ; le recalcul des stocks juste après, selon le guide sur le stock ; l'export comptable par lots à minuit, vers le format que le cabinet attend selon le guide sur l'intégration ; la préparation du rapport du lundi à 2 h, manquée parce que le serveur a redémarré à 2 h 04 et reprise par la rattrapeuse à 2 h 15 ; les 1 200 rappels de rendez-vous du jour à 6 h 30, en lots de cent, un message par seconde, selon le guide sur la réservation ; le rapport envoyé au gérant à 7 h. L'exécutant B fait les tâches courtes en parallèle : le nettoyage des fichiers temporaires, qui attend la fin de la sauvegarde parce que le verrou est pris ; les relances de paiement à 23 h 30 ; le recalcul des créneaux de la semaine suivante à 5 h 30.

Trois choses se seraient mal passées sans la file : le rapport de 2 h n'aurait pas existé et personne ne l'aurait su ; le nettoyage aurait tourné pendant la sauvegarde ; les 1 200 rappels seraient partis en dix secondes et le compte aurait été bloqué. Combien d'exécutants, sur quelle machine, et où, est une décision décrite dans le guide sur l'hébergement ; les horaires de la figure sont un exemple construit.

«Une tâche planifiée a une heure, mais aussi une rattrapeuse si le serveur était éteint, un verrou pour ne pas tourner deux fois, un débit pour ne pas se faire couper, et un journal qui dit à 7 h ce qui a tourné.»

Vu ailleurs : la recommandation d'AWS sur les reprises, et ce qui se transpose

Trois faits se transposent tels quels. L'attente exponentielle avec hasard : l'équipe architecture d'Amazon Web Services a montré, par simulation, que doubler l'attente entre les tentatives réduit peu la contention tant que les clients réessaient en même temps, et que le remède est d'ajouter du hasard, ce qui dans leur simulation à cent clients a divisé le nombre d'appels par plus de deux ; ce qui se transpose, c'est un barème d'attente avec hasard et plafond, écrit la première semaine. La livraison au moins une fois : une file qui garantit qu'une tâche sera exécutée garantit par là même qu'elle peut l'être deux fois, après une coupure au mauvais moment ; ce qui se transpose, c'est que chaque tâche porte une clé et que son travail est idempotent, comme les webhooks de paiement décrits dans le guide sur le paiement en ligne. La file des échecs, ou lettre morte, présente dans tous les systèmes de messages ; ce qui se transpose, c'est qu'elle est lue par un humain, pas seulement stockée.

Ce que ces faits ne décident pas pour vous : combien de tentatives, quel plafond, quel débit vers votre fournisseur, qui est alerté et à quelle heure part le rapport ; la première semaine du projet y répond, et c'est le gérant qui signe.

Les règles des tâches en arrière-plan qui tiennent

Six règles, écrites la première semaine. Rien de long ne tourne dans l'écran : tout devient une tâche. Chaque tâche porte une clé et son travail est idempotent. Une tâche est verrouillée par un bail, renouvelé ou relâché. L'échec a un barème : attente qui double, hasard, plafond, puis file des échecs et alerte. Les envois ont un débit écrit par fournisseur. Ce qui a tourné est lisible par le gérant à 7 h, avec ce qui n'a pas tourné.

Et une règle de méthode : les scripts de nuit existants ne sont pas réécrits d'un coup ; ils deviennent des tâches un par un, en commençant par celui dont l'échec coûte le plus cher, et chaque bascule se fait avec son journal, selon le guide sur la livraison sans casse.

Six entreprises, et la tâche qui manquait

Six situations composées à partir de projets que nous rencontrons ; les noms sont génériques et les chiffres sont des exemples.

Un cabinet médical à Alger, rappels de rendez-vous. Les rappels partaient deux fois certains matins, parce que deux serveurs lançaient le même script. La construction : tâches de cent envois, verrou avec bail, clé par rappel. Les doublons ont cessé le premier jour.
Un grossiste à Sétif, export comptable. L'export de fin de mois plantait dans le navigateur au-delà de dix mille lignes. La construction : tâche en arrière-plan par lots, fichier déposé, lien envoyé au cabinet, reprise au lot ; le format suit le guide sur l'intégration.
Un fondateur à Lyon, boutique en ligne à Alger. Le rapport de nuit n'arrivait plus depuis une mise à jour du serveur, et il l'a découvert trois semaines plus tard. La construction : rattrapeuse au démarrage, alerte si le rapport n'est pas parti à 7 h 15 ; la gestion à distance suit le guide sur le commerce depuis la France.
Une plateforme de livraison à Oran, notifications. Le fournisseur SMS a coupé le compte après une rafale de deux mille messages. La construction : débit lissé par fournisseur, lots, reprises avec hasard quand il est indisponible.
Un distributeur à Constantine, recalcul de stock. Un recalcul bloqué tenait la file toute la nuit et rien d'autre ne tournait. La construction : durée maximale, bail expiré qui relâche la tâche et la marque, file qui avance.
Une PME à Annaba, imports fournisseurs. Les imports de prix tournaient dans l'écran et plantaient à la coupure. La construction : import en tâche par lots avec reprise et clé, selon le guide sur l'import Excel.

Le calendrier 2027

Six semaines pour une application qui a déjà des scripts de nuit et des envois ; la première semaine se passe sans code.

Figure 6 · Six semaines, et la première sans code : l’inventaire de tout ce qui tourne sans écran est ce que personne n’a jamais écrit, et c’est ce qui dit combien de tâches, quels débits et qui est alerté. La troisième semaine est accentuée parce que les reprises et la file des échecs sont ce qui fait qu’une panne du fournisseur est un retard et pas une perte.

Semaine 1, inventaire des tâches : tout ce qui tourne sans écran, envois, exports, recalculs, rapports, relances, avec priorité, échéance, débit, durée maximale et qui est alerté ; signé par le gérant. Semaine 2, file et exécutants : table de tâches dans la base, exécutants, verrou avec bail, durée maximale, tableau des tâches dans l'application. Semaine 3, reprises et échecs : barème d'attente avec hasard et plafond, clé d'idempotence, file des échecs, alerte, relance manuelle.

Semaine 4, planification : tâches à heure fixe, rattrapeuse au démarrage, verrous entre tâches, débit lissé pour les envois. Semaine 5, migration des scripts : les scripts de nuit existants deviennent des tâches, un par un, avec leur journal ; les envois passent par la file. Semaine 6, mesure : journal du matin, tâches en retard et en échec, taille de la file, première cause d'échec de la semaine, sur le tableau de bord selon le guide sur le tableau de bord temps réel. Chaque semaine se termine par une démonstration.

Ce qui fait échouer les tâches en arrière-plan

Cinq causes, vues dans des applications qu'on reprend. Le script de minuit sans trace : il échoue en silence pendant trois semaines. L'envoi déclenché par un clic : l'employé clique deux fois, ou deux employés cliquent. L'export dans le navigateur : la connexion coupe, tout est perdu. La reprise immédiate et infinie : le fournisseur tombé est martelé jusqu'à ce qu'il bloque le compte. La file sans humain : la file des échecs grossit et personne ne la lit.

Et une cause de méthode : traiter chaque tâche comme un cas unique, avec son script et sa logique de reprise. Une file de travaux est une machine qu'on construit une fois et que toutes les tâches utilisent.

Questions fréquentes

Les questions que posent les gérants et les fondateurs quand ils nous décrivent des envois qui partent deux fois et des rapports qui ne partent pas.

Pourquoi le rapport de nuit n'est-il pas parti ?: Le plus souvent parce qu'un script est lancé à heure fixe par le système et que le serveur était en train de redémarrer, ou que le script a échoué sans que personne ne soit alerté. La construction qui règle cela : une tâche planifiée dans une file, une rattrapeuse au démarrage qui reprend les heures manquées, et une alerte si le rapport n'est pas parti à l'heure prévue plus un délai.
Pourquoi les SMS sont-ils partis deux fois ?: Parce que deux serveurs ou deux clics ont lancé le même envoi, ou qu'une reprise a renvoyé des messages déjà partis. La construction : un verrou avec bail dans la base de données pour qu'une tâche ne soit prise qu'une fois, et une clé d'idempotence par message pour qu'un message déjà envoyé ne reparte jamais, même après une reprise.
Qu'est-ce qu'une file de travaux ?: Une table de tâches dans la base de données, avec un état, une priorité, une échéance, une charge, une clé et un bail, et des exécutants qui prennent la tâche suivante, la verrouillent, l'exécutent et notent le résultat. Tout ce qui ne doit pas bloquer l'écran y passe : envois, exports, recalculs, rapports, relances, imports.
Comment réessayer sans aggraver la panne du fournisseur ?: Avec une attente qui double entre les tentatives, tirée au hasard dans une fenêtre pour que mille tâches ne repartent pas à la même seconde, et plafonnée. C'est la recommandation publiée par l'équipe architecture d'Amazon Web Services. Après le dernier essai, la tâche va dans la file des échecs avec une alerte.
Que devient une tâche qui échoue définitivement ?: Elle va dans la file des échecs, avec sa cause, sa charge et son nombre de tentatives, et une alerte part au responsable. Un humain lit cette file chaque matin, relance ou corrige. Elle n'est jamais supprimée en silence.
Combien d'exécutants faut-il ?: Pour la plupart des PME, deux suffisent : un pour les tâches lourdes, une à la fois, et un pour les tâches courtes en parallèle ; on en ajoute quand la file grossit, et c'est un chiffre qu'on mesure plutôt qu'on devine. Où tournent ces exécutants dépend de l'hébergement choisi.
Combien de temps pour mettre cela en place ?: Six semaines dans le calendrier type : une pour l'inventaire des tâches, une pour la file et les exécutants, une pour les reprises et la file des échecs, une pour la planification, une pour la migration des scripts existants, une pour la mesure. Le délai dépend du nombre de scripts existants et de fournisseurs d'envoi.