Réponse courte. Un tableau de bord temps réel n'est pas une requête sur la base de la caisse à chaque fois que le gérant ouvre l'écran ; c'est une chaîne : chaque vente, annulation, livraison ou paiement devient un événement dans une file ; une définition par chiffre, écrite une fois dans le code avec le comptable, dit ce que « chiffre d'affaires du jour » veut dire, taxes comprises ou non, retours déduits, heure de coupure ; des compteurs par magasin, produit et heure sont incrémentés à l'arrivée de l'événement et lus en mémoire, jamais recalculés ; l'écran affiche l'heure de la dernière mise à jour à côté de chaque chiffre ; un flux serveur vers le téléphone pousse les nouveautés et se reconnecte seul ; la nuit, tout est recompté depuis les événements pour que le chiffre du jour et la comparaison du mois aient la même définition ; et des alertes WhatsApp sur seuils et silences remplacent la surveillance de l'écran. Dix semaines, dont la première sans code, consacrée aux dix chiffres et à leurs définitions.
Ce guide s'adresse au gérant de plusieurs magasins qui reçoit un fichier le lundi et apprend le jeudi qu'une caisse était en panne, au fondateur installé en France qui veut voir ses ventes en Algérie sur son téléphone sans appeler, au distributeur dont les chiffres de la prévente et de la comptabilité ne se rejoignent jamais, et à celui qui lit « dashboard temps réel » dans un devis sans savoir ce qui se cache derrière. Il ne compare pas les outils de business intelligence, ce que fait le guide sur la BI en Algérie ; il décrit ce qu'on construit pour que le chiffre soit juste, frais et lisible sur un téléphone.
Ce que les chiffres disent
Le téléphone du gérant est devenu un écran suffisant. Selon le rapport Digital 2026 de DataReportal pour l'Algérie, publié le 8 novembre 2025, le pays comptait 37,8 millions d'internautes en octobre 2025, soit 79,5 % de la population, et 55,6 millions de connexions mobiles fin 2025 d'après GSMA Intelligence ; la vitesse médiane de téléchargement mobile mesurée par Ookla atteignait 41,21 Mbit/s, en hausse de 65,5 % sur les douze mois précédant août 2025, et la vitesse fixe médiane 37,86 Mbit/s. Le 17 mai 2026, un communiqué du ministère de la Poste et des Télécommunications relayé par Radio Algérie annonçait qu'Alger entrait au 48e rang mondial du classement Ookla des villes pour l'internet mobile, contre le 116e en septembre, avec un débit descendant de 163,31 Mbit/s ; c'est Alger, sur Speedtest, après l'ouverture de la 5G fin 2025, et d'autres mesureurs donnent des médianes nationales bien plus basses. Ce que cela impose : l'écran du gérant doit s'ouvrir vite sur une bonne 4G à Alger et rester lisible sur un réseau médiocre dans une wilaya, ce qui se décide dans l'architecture, pas dans la maquette.
La technique qui porte le temps réel est ordinaire et documentée. Les événements envoyés par le serveur, décrits par Google sur web.dev, poussent des mises à jour au navigateur sur une connexion HTTP ordinaire, se reconnectent seuls après une coupure, avec un délai par défaut d'environ trois secondes, et renvoient au serveur l'identifiant du dernier événement reçu pour reprendre où ils en étaient ; c'est exactement ce qu'il faut pour un écran qui lit et ne parle pas, là où les WebSockets, bidirectionnels, servent aux messageries et aux jeux. Côté base, la documentation de PostgreSQL décrit le rafraîchissement d'une vue matérialisée qui « remplace complètement le contenu », avec une option qui évite de bloquer les lectures à condition qu'un index unique existe ; c'est l'outil des comparaisons recomptées la nuit. Pour les compteurs de la journée, des extensions comme TimescaleDB décrivent des agrégats continus qui ne recalculent que les tranches de temps modifiées, selon la documentation de l'éditeur ; nous obtenons le même effet, plus simplement, par des compteurs incrémentés à l'événement.
Le reste est algérien et ne figure dans aucun rapport : la caisse sous Windows qui exporte un fichier à la fermeture, le gérant qui pilote six magasins par appels WhatsApp, l'heure de coupure à 23 h dans un magasin et à minuit dans l'autre, le fichier du lundi qu'un employé prépare le dimanche. Nous n'avons trouvé ni étude sur le délai acceptable d'un chiffre ni mesure des tableaux de bord en Algérie ; nous l'avons observé : un chiffre que le gérant ne croit pas n'est pas regardé, et un chiffre qu'il croit est regardé dix fois par jour. Ce guide dit comment on obtient le second.
La vie d'un chiffre, de la vente au téléphone du gérant, en six moments
Le tableau de bord ne se décrit pas par ses graphiques mais par ce qui arrive à une vente, de la caisse d'un magasin au téléphone du gérant, et par ce qui empêche le chiffre d'être faux en route.
L'événement naît quand une vente est encaissée dans la caisse ou dans l'application : horodaté, avec le magasin, la source et une clé d'idempotence, déposé dans une file persistante, jamais compté deux fois même si la caisse renvoie le même ticket après une coupure, par le mécanisme que le guide sur l'application hors ligne décrit ; une annulation ou un retour est un événement négatif qui traverse la même file, pas une ligne effacée. La définition est le moment qui évite les deux chiffres : « chiffre d'affaires du jour » est écrit une fois dans le code, avec le comptable, taxes comprises ou non, retours déduits, heure de coupure, fuseau, magasins inclus, et versionné ; la caisse, l'écran du gérant et le rapport du comptable lisent la même définition. L'agrégat est un compteur par magasin, par produit et par heure, incrémenté à l'arrivée de l'événement ; quand le gérant ouvre l'écran, rien n'est recalculé et la base qui sert les caisses n'est pas touchée.
Le cache et la fraîcheur : l'écran lit les compteurs en mémoire et affiche, à côté de chaque chiffre, l'heure de sa dernière mise à jour ; un chiffre sans heure est un chiffre dont on ne sait pas s'il est vieux. La diffusion pousse les nouveaux compteurs du serveur vers le téléphone par un flux d'événements qui se reconnecte seul après une coupure de réseau et reprend au dernier événement reçu ; l'écran du gérant est une application installable, décrite dans le guide sur la PWA, qui montre les derniers compteurs connus même hors connexion, avec leur heure. L'alerte remplace la surveillance : un seuil de stock franchi, un écart inhabituel avec la même journée de la semaine passée, une caisse qui n'a rien envoyé depuis une heure en pleine journée, et un message WhatsApp part vers le gérant avec le chiffre et le lien, par la plateforme décrite dans le guide sur l'agent WhatsApp.
Le tableau de bord temps réel, en cinq couches
Derrière les six moments, cinq couches, et celle du milieu est la seule qu'on construit vraiment.
Les sources sont les caisses, l'application de terrain, le portail de commande, l'agent WhatsApp, la comptabilité et la banque ; chacune a son connecteur, API, fichier ou lecture de base, selon le guide sur l'intégration des logiciels existants, et chacune émet des événements dans le même format. Les événements vivent dans une file persistante avec horodatage, clé d'idempotence, source, et les corrections comme événements à part entière ; c'est la vérité depuis laquelle tout se recompte. Les agrégats et définitions sont le vrai livrable : des compteurs par magasin, produit, heure et client, des définitions versionnées avec un propriétaire par chiffre, et un recalcul nocturne depuis les événements qui vérifie que les compteurs du jour n'ont pas dérivé.
La diffusion est une API de lecture, un flux serveur vers le téléphone, un cache, et l'application installable du gérant, qui s'ouvre en moins d'une seconde sur un réseau mobile ordinaire parce qu'elle ne demande que des compteurs déjà prêts. Les alertes et la lecture : des seuils par magasin et par produit, des écarts, des silences, des messages WhatsApp, et la comparaison à la même journée de la semaine passée plutôt qu'à la veille ; le gérant ne regarde pas l'écran toute la journée, l'écran vient à lui quand il le faut. Les couches du dessous décident si la caisse ralentit ; les couches du dessus décident si le gérant regarde encore dans trois mois. Le même tableau de bord sert au fondateur qui pilote depuis la France, décrit dans le guide sur le commerce géré à distance.
«Un tableau de bord qui interroge la base de la caisse à chaque ouverture est un rapport ; le tableau de bord, c'est l'événement, la définition, le compteur et l'heure affichée.»
Un exemple chiffré
Un exemple sur des hypothèses d'usage, avec une mécanique qui n'en est pas : une chaîne de six magasins, un gérant à Alger, un comptable externe.
Six magasins avec chacun sa caisse, plus un portail de commande pour les détaillants ; chaque vente, annulation et commande devient un événement en quelques secondes, par le connecteur de la caisse ou par l'application. Quinze secondes entre la vente encaissée et le chiffre mis à jour sur le téléphone du gérant : c'est notre hypothèse, qui dépend du connecteur de la caisse et du réseau, et c'est ce que le pilote mesure sur de vrais magasins ; une caisse qui n'exporte qu'à la fermeture donne un chiffre à jour le soir, et l'écran le dit avec son heure. Une définition du chiffre d'affaires au lieu de trois : la caisse, l'écran et le comptable disent la même chose à la même heure de coupure, et le rapport du lundi, celui que l'employé préparait le dimanche, s'arrête après le premier mois de rapprochement.
Moins d'une seconde pour ouvrir l'écran sur un réseau mobile ordinaire est le résultat qui ne dépend d'aucune hypothèse : les compteurs sont lus en mémoire, aucune requête lourde ne touche la base de production, et l'application installée montre les derniers compteurs connus avant même que le réseau réponde. Ce que l'exemple montre : avec six magasins et un gérant qui ouvre l'écran dix fois par jour, le tableau de bord « requête à l'ouverture » fait soixante requêtes lourdes par jour sur la base qui sert les caisses, aux heures de pointe ; le tableau de bord à compteurs n'en fait aucune. Les hypothèses à vérifier chez vous : combien de sources, quel mode d'export pour chaque caisse, combien de chiffres le gérant regarde vraiment ; la première semaine du projet y répond.
Six chiffres du gérant et la fraîcheur qui convient à chacun
Tout n'a pas besoin d'être en temps réel, et vouloir tout en temps réel coûte cher pour rien ; la fraîcheur se décide chiffre par chiffre, selon la décision qu'il déclenche.
Le chiffre d'affaires du jour par magasin veut quelques secondes à une minute : c'est le chiffre que le gérant regarde dix fois par jour, et c'est un compteur incrémenté à chaque événement de vente ou d'annulation, avec l'heure de coupure dans la définition. Le stock critique se contente de quelques minutes : un compteur par produit et par magasin, un seuil par produit, et une alerte quand il est franchi, parce que personne ne surveille un écran de stock. Les encaissements contre la caisse se vérifient en fin de journée : c'est le rapprochement entre événements de vente, terminal de paiement et relevé que décrit le guide sur la caisse, et il liste les écarts plutôt que de les cacher.
Les encours clients veulent l'heure : les événements de facture et de paiement arrivent de la comptabilité ou du portail B2B, décrit dans le guide dédié, et un compteur par client dit qui dépasse son crédit. Les livraisons en cours veulent quelques secondes : les statuts sont poussés par l'application des livreurs décrite dans le guide sur la plateforme de livraison, un compteur par statut et par zone, une alerte sur retard. La comparaison semaine et mois se recompte la nuit, dans une vue matérialisée rafraîchie depuis les événements avec la même définition que le chiffre du jour ; c'est ce qui permet de dire « ce mardi contre le mardi d'il y a une semaine » sans que les deux chiffres aient été comptés différemment.
Six situations qui font douter du tableau de bord
Six situations que nous voyons sur les tableaux de bord que nous reprenons, et ce que l'architecture fait contre chacune.
Deux écrans, deux chiffres est la première cause d'abandon : la caisse dit 412 000 dinars, l'écran 398 000, le comptable un troisième chiffre, et la différence vient de trois définitions, taxes, retours, heure de coupure ; la parade est une définition par chiffre, écrite dans le code, versionnée, que tous les écrans lisent, et un rapprochement mensuel avec le comptable qui corrige la définition quand elle est fausse. Le tableau de bord qui ralentit la caisse : à 18 h, les vendeurs attendent parce que le gérant a ouvert son écran et que l'écran a lancé une requête sur la base de production ; compteurs mis à jour à l'événement et lus en mémoire, zéro requête lourde. Le chiffre faux à 2 h du matin : la journée de la caisse finit à 23 h, celle de l'écran à minuit, celle du serveur en temps universel ; heure de coupure et fuseau écrits dans la définition, et la journée du gérant est celle de ses magasins.
La page qui tourne sur la 3G : quatre secondes d'attente dans une wilaya et le gérant ferme ; application installable, compteurs en cache, écran léger, et « mis à jour il y a » visible même hors connexion. La vente annulée qui reste comptée : un retour en caisse ne redescend pas le chiffre ; l'annulation est un événement négatif qui traverse la même file, et le recalcul nocturne depuis les événements attrape ce qui aurait dérivé. Le gérant qui ne regarde plus : l'écran est beau et personne ne l'ouvre après trois semaines ; des alertes WhatsApp sur seuils et silences, dix chiffres au plus, et la comparaison à la même journée de la semaine passée, qui est la seule qui veut dire quelque chose un vendredi. La première coûte la confiance, les autres coûtent la vitesse de la caisse ou l'attention du gérant, et aucune ne se règle dans la mise en page.
«Deux chiffres se réparent avec une définition, pas avec un graphique.»
Vu ailleurs : web.dev, PostgreSQL, Ookla, et ce qui se transpose
Trois textes publics disent l'essentiel. Google, sur web.dev, décrit les événements envoyés par le serveur : une connexion HTTP ordinaire, des mises à jour poussées dans un sens, une reconnexion automatique avec un délai par défaut d'environ trois secondes, et l'identifiant du dernier événement renvoyé au serveur pour reprendre ; ce qui se transpose, c'est que l'écran d'un gérant n'a pas besoin de WebSockets ni d'une infrastructure spéciale, il a besoin d'un flux qui se reconnecte seul et d'un serveur qui sait rejouer ce qui a été manqué, et ce second point est à la charge de celui qui construit. PostgreSQL décrit la vue matérialisée dont le rafraîchissement remplace tout le contenu, avec une option qui ne bloque pas les lectures si un index unique existe ; ce qui se transpose, c'est de réserver cet outil aux comparaisons recomptées la nuit et de ne jamais en faire la source du chiffre du jour.
Ookla, via DataReportal et le communiqué du ministère, dit que le réseau mobile algérien s'est beaucoup amélioré, surtout à Alger ; ce qui se transpose, c'est que l'écran peut être riche sur une bonne 4G, et ce qui ne se transpose pas, c'est le débit d'Alger dans une wilaya un soir de pointe, d'où l'application installable, le cache et l'heure de fraîcheur affichée. Ce que ces textes ne disent pas : quels dix chiffres votre gérant regarde vraiment, et avec quelle définition votre comptable les calcule ; c'est la première semaine du projet, pas une documentation, qui y répond.
Les règles d'un tableau de bord qui reste regardé
Six règles, écrites la première semaine et relues à chaque chiffre ajouté. Dix chiffres au plus, chacun avec son propriétaire, sa définition et sa fraîcheur utile ; un tableau de bord de quarante chiffres n'est regardé par personne. Une définition par chiffre, écrite dans le code, avec le comptable, versionnée, et la même pour la caisse, l'écran et le rapport. Les compteurs se mettent à jour à l'événement, jamais à l'ouverture de l'écran, et la base de production n'est pas touchée par la lecture. Chaque chiffre affiche son heure ; un chiffre sans heure de fraîcheur n'est pas affiché. La nuit recompte tout depuis les événements, et un écart entre le compteur du jour et le recalcul est une alerte, pas un détail. Les alertes remplacent la surveillance : seuils, écarts, silences, par WhatsApp, et pas plus de quelques-unes par jour, sinon elles ne sont plus lues.
Une septième règle porte sur le cahier des charges : « tableau de bord temps réel » n'est pas une exigence, c'est une phrase ; l'exigence s'écrit « le chiffre d'affaires du jour par magasin est mis à jour dans la minute qui suit la vente, avec sa définition écrite et son heure affichée ; l'écran s'ouvre en moins d'une seconde sur réseau mobile ; aucune requête de l'écran ne touche la base des caisses ; les chiffres sont recomptés chaque nuit depuis les événements ; les écarts avec la comptabilité sont rapprochés chaque mois », et elle se vérifie à la recette, comme le recommande le guide sur le cahier des charges. Un devis qui chiffre « un dashboard » sans dire d'où viennent les événements ni qui écrit les définitions a chiffré des graphiques.
Six entreprises, ce qu'on met sur l'écran du gérant
Six entreprises que nous équipons souvent, et pour chacune les chiffres retenus la première semaine.
- La chaîne de magasins. Chiffre d'affaires du jour par magasin, panier moyen, stock critique, encaissements contre caisse le soir ; alerte quand une caisse se tait en pleine journée.
- Le distributeur avec prévendeurs, décrit dans le guide dédié. Commandes prises par tournée, taux de visite, encours par détaillant, livraisons en cours ; alerte sur un détaillant qui dépasse son crédit.
- Le fondateur en France. Les mêmes chiffres que le gérant local, sur le même écran, avec les alertes WhatsApp à l'heure de Paris ; la comparaison à la semaine passée plutôt que l'appel du soir.
- La clinique ou le cabinet. Rendez-vous du jour, taux d'absence, actes facturés, encaissements ; alerte quand les rendez-vous de demain ne sont pas confirmés.
- La plateforme de livraison. Colis en cours par statut et par zone, délais, retours, paiements à la livraison encaissés contre déclarés ; alerte sur retard et sur écart d'encaissement.
- Le SaaS vendu à des entreprises, décrit dans le guide sur le SaaS multi-tenant. Un tableau de bord par client sur la même plateforme, compteurs par tenant, définitions communes ; le fondateur voit l'usage de tous, chaque client ne voit que le sien.
Le calendrier 2027
Le calendrier est celui d'un tableau de bord en dix semaines, dont la première sans code et les deux dernières de pilote sur deux magasins réels.
La semaine 0 à 1 écrit les définitions : dix chiffres au plus, chacun avec sa définition écrite avec le comptable, sa fraîcheur utile, son propriétaire et le seuil qui déclenche une alerte ; c'est la semaine qui décide si le gérant croira l'écran. La semaine 1 à 2 branche les sources : caisses, application, portail, comptabilité, chacune par son connecteur, chacune émettant des événements dans le même format. Les semaines 2 à 4 construisent les événements et les compteurs : file, idempotence, annulations comme événements négatifs, compteurs par magasin, produit et heure, recalcul nocturne depuis les événements, et un test qui compare les deux à chaque livraison. Les semaines 4 à 6 font l'écran et la diffusion : application installable du gérant, lecture en cache, flux serveur avec reconnexion et reprise, heure de fraîcheur affichée, et un test sur réseau mobile dégradé.
La semaine 6 à 7 pose les alertes WhatsApp : seuils par magasin et par produit, écarts inhabituels, caisse muette, avec le chiffre et le lien dans le message. La semaine 7 à 8 rapproche les chiffres de l'écran avec ceux du comptable sur un mois complet : les écarts sont expliqués, les définitions corrigées, et c'est ce qui rend l'écran crédible. Les semaines 8 à 10 sont le pilote sur deux magasins, avec le délai réel mesuré entre la vente et l'écran, puis la bascule des six ; le rapport du lundi s'arrête quand le gérant ne le demande plus. Ce que coûte ensuite une année de ce tableau de bord, serveurs, messages et mises à jour comprises, entre dans le budget décrit par le guide sur la vie d'une application.
Ce qui fait échouer un tableau de bord
Les tableaux de bord que nous reprenons échouent presque toujours pour l'une de ces raisons.
- La requête à l'ouverture. L'écran interroge la base des caisses à chaque fois ; le gérant regarde, les vendeurs attendent.
- Trois définitions du même chiffre. La caisse, l'écran et le comptable ne disent pas la même chose, et le gérant ne croit plus personne.
- Pas d'heure de fraîcheur. Un chiffre de la veille affiché comme s'il était de l'instant ; le jour où le gérant s'en aperçoit, l'écran est mort.
- L'annulation effacée. Le retour supprime une ligne au lieu d'ajouter un événement ; rien ne se recompte, tout dérive.
- Quarante chiffres. Tout le monde a voulu le sien ; personne ne regarde aucun.
- Pas de rapprochement avec le comptable. L'écran vit sa vie, la comptabilité la sienne, et l'écart du mois se découvre au bilan.
- Le beau graphique sur une page lourde. Quatre secondes sur la 3G d'une wilaya, et le gérant retourne aux appels WhatsApp.
Questions fréquentes
Les questions que nous recevons de gérants, de fondateurs installés en France et de comptables.
- Temps réel, ça veut dire quoi exactement pour un gérant ?
- Que le chiffre du jour se met à jour dans la minute qui suit la vente, avec son heure affichée, sans que le gérant rafraîchisse ni que la caisse ralentisse. Le reste, stock, encours, comparaisons, a sa propre fraîcheur, de quelques minutes à la nuit, décidée chiffre par chiffre selon la décision qu'il déclenche.
- Pourquoi la caisse, l’écran et le comptable ne donnent-ils jamais le même chiffre ?
- Parce qu'ils appliquent trois définitions : taxes comprises ou non, retours déduits ou pas, journée qui finit à 23 h, à minuit ou en temps universel. La parade est une définition par chiffre écrite une fois dans le code avec le comptable, lue par tous les écrans, et un rapprochement mensuel qui la corrige quand elle est fausse.
- Le tableau de bord va-t-il ralentir la caisse ?
- Pas s'il est construit sur des événements et des compteurs : la caisse émet un événement, le compteur s'incrémente, et l'écran lit le compteur en mémoire sans toucher la base de production. Un tableau de bord qui interroge la base de la caisse à chaque ouverture la ralentit, et c'est le premier défaut que nous corrigeons.
- Ma caisse sous Windows n’a pas d’API. Peut-on quand même avoir le chiffre ?
- Oui : la plupart exportent un fichier à la fermeture ou toutes les heures, et un connecteur le lit et le transforme en événements ; le chiffre est alors à jour à chaque export, et l'écran le dit avec son heure. Quand la caisse est remplacée ou reliée en direct, le connecteur change et l'écran ne bouge pas.
- Et pour un gérant qui vit en France ?
- Le même écran, la même application installable, les mêmes compteurs ; les alertes WhatsApp arrivent à l'heure de Paris, et la comparaison à la même journée de la semaine passée remplace l'appel du soir. C'est le cas que le guide sur le commerce géré depuis la France décrit du point de vue du propriétaire.
- Combien de temps pour construire le tableau de bord ?
- Dix semaines, dont la première sans code pour écrire les dix chiffres et leurs définitions avec le comptable, deux semaines de pilote sur deux magasins, et une semaine de rapprochement avec la comptabilité qui rend l'écran crédible. Le connecteur d'une caisse sans API est ce qui allonge le plus souvent le calendrier.