Cette page décrit le fonctionnement réel du système, sans raccourci commercial. Elle indique aussi, à chaque étape, ce qui a été éprouvé et ce qui ne l'est pas encore.
Cinq étapes séparent l'appui sur le bouton de la réception du SMS. Les trois premières se passent dans la balise, les deux dernières sur nos serveurs.
La balise dort en permanence pour économiser sa batterie. L'appui la réveille, mais elle ne fait rien tant qu'il n'a pas duré deux secondes. Un frottement dans un sac ne déclenche donc pas d'alerte. Un retour vibrant confirme la prise en compte.
Le récepteur satellite de navigation cherche la position, et le niveau de batterie est mesuré. L'ensemble est enregistré dans la mémoire de la balise avant toute tentative d'envoi : si l'appareil s'éteint en cours de route, l'alerte n'est pas perdue et repart au rallumage.
Le message est volontairement minuscule. Chaque octet transmis a un coût réel sur un abonnement satellite, et plus le message est court, plus il a de chances de passer avec un signal faible. Si l'envoi échoue, la balise se rendort et réessaie automatiquement cinq minutes plus tard, sans intervention.
L'opérateur satellite transmet la trame à notre serveur. Celui-ci la décode et retrouve le propriétaire à partir du seul identifiant que la balise connaisse : le numéro de série de son modem. Aucune donnée personnelle ne circule dans le message.
Chaque contact enregistré reçoit un SMS contenant les coordonnées et un lien de carte, lisible sur n'importe quel téléphone, même sans application installée. Un échec d'envoi vers un contact n'empêche jamais les autres d'être prévenus.
Neuf octets, pas un de plus. Ce format est le contrat entre le programme de la balise et le serveur : les deux le définissent à l'identique.
| Position | Contenu | Codage |
|---|---|---|
| 0 – 3 | Latitude | Entier signé, degrés × 1 000 000 |
| 4 – 7 | Longitude | Entier signé, degrés × 1 000 000 |
| 8 | Batterie | Entier de 0 à 100 |
Ce codage conserve la position à environ onze centimètres près, très en deçà de ce que le récepteur lui-même peut atteindre. La précision perdue vient donc du capteur, jamais du format.
La distinction est faite ici parce qu'elle est la seule chose qui compte pour juger un projet à ce stade.
Les valeurs annoncées ailleurs sur ce site sont des objectifs de conception. Aucune n'a été mesurée sur un prototype, pour la simple raison qu'il n'en existe pas encore.
Un service de données par paquets courts se paie de deux façons : un abonnement mensuel par appareil, et chaque message envoyé. L'ignorer serait passer à côté de la contrainte principale du projet.
| Poste | Ordre de grandeur | Nature |
|---|---|---|
| Module Iridium 9603, à l'unité | 220 € | Prix relevé, achat unitaire |
| Ligne satellite, par mois activé | 15 € | Estimation, contrat non signé |
| Un message d'alerte | 0,09 à 0,37 € | Estimation, selon le forfait |
| Tous composants, par balise | 315 € | Somme des prix unitaires |
Le module satellite représente à lui seul plus des deux tiers du coût matériel. C'est ce qui fixe le prix plancher de la balise, et c'est aussi pourquoi le premier exemplaire n'a pas encore été assemblé.
La capacité de la batterie n'est pas encore arrêtée. Plutôt que d'annoncer une autonomie, voici le calcul qui permettra de la choisir.
| Poste | Hypothèse | Coût énergétique |
|---|---|---|
| Veille profonde, deux semaines | 10 µA × 336 h | ≈ 3,4 mAh |
| Une acquisition de position | ≈ 30 mA × 30 s | ≈ 0,25 mAh |
| Une transmission satellite | ≈ 190 mA × 30 s | ≈ 1,6 mAh |
| Une alerte complète | acquisition puis transmission | ≈ 1,9 mAh |
Ce que ce calcul montre, et ce qu'il ne montre pas. Deux semaines de veille suivies de dix alertes coûtent environ 22 mAh ; cinquante alertes en coûtent 98. Une batterie de quelques centaines de milliampères-heures suffirait donc largement. Autrement dit, ce n'est pas l'usage qui limitera l'autonomie, mais l'autodécharge de la batterie et la consommation résiduelle des circuits, que seule une mesure sur prototype révélera. Les consommations utilisées ici viennent des fiches techniques des composants retenus ; aucune n'a été relevée sur du matériel Teskideh.
Ce dessin est un rendu de conception. Aucun exemplaire n'a été fabriqué : ni les dimensions, ni la résistance, ni l'autonomie n'ont été mesurées sur du matériel.
Ouvrir le dessin en pleine taille
Ce que ce dessin est, et ce qu'il n'est pas. Les composants représentés correspondent à ceux du programme déjà écrit : microcontrôleur ESP32-S3, modem Iridium 9603, récepteur GNSS, batterie LiFePO4. Les cotes portées sur le dessin sont des cibles de conception. La tenue à la poussière et à l'eau est un objectif visé, pas une certification : une norme de ce type s'obtient par essai en laboratoire, et aucun essai n'a été mené.
Ce qui suit décrit l'implémentation actuelle, telle qu'elle tourne aujourd'hui, pas une intention.
Les positions sont enregistrées dans une base PostgreSQL hébergée chez Supabase, avec l'heure du relevé et l'état de la batterie. Les échanges entre l'application, le site et le serveur passent par une liaison chiffrée.
Chaque table est protégée par des règles vérifiées côté serveur, quarante-sept au total sur quinze tables. Un compte ne peut lire que ses propres données. Un proche invité au centre familial y accède en lecture seule, et seulement tant que l'invitation n'est pas révoquée. Une organisation ne voit que les balises qui lui sont rattachées.
Aucune suppression automatique n'est en place à ce jour : une alerte reste tant que son propriétaire ne l'efface pas. Chaque alerte peut être supprimée depuis l'historique, et la suppression du compte efface l'ensemble des données associées en cascade. Une durée de conservation sera définie avant le déploiement.