Volet mobile du cahier des charges

Soixante-quatorze exigences pour les applications iOS et Android. Aucune ligne
de code écrite : c'est un document de conception, et il le dit.

La thèse, en une phrase
  Une application mobile n'emporte pas le cockpit dans une poche. Elle fait les
  quelques gestes qu'un téléphone fait mieux qu'un ordinateur — et le premier
  d'entre eux, le seul qui justifie vraiment deux applications de plus à
  maintenir, c'est réveiller quelqu'un à trois heures du matin.

  Tout le reste du document découle de là. Six gestes, pas un de plus, et le
  renvoi assumé au web pour tout ce qui demande un grand écran. Le rembobinage
  n'est pas porté : relire une crise est un travail d'analyse, et le faire sur
  un téléphone produirait des conclusions prises de travers.

Ce qui distingue ce volet d'un cahier des charges mobile ordinaire

  La règle du heurtoir. Une notification traverse les serveurs d'Apple et de
  Google : ce qu'elle contient, ils le voient. Elle frappe donc à la porte
  sans glisser de message dessous — ni intitulé de crise, ni nom
  d'organisation. Le contenu se récupère après déverrouillage.

  L'alerte critique demandée, et construite comme si elle était refusée. Apple
  l'accorde avec parcimonie. Un produit qui promet de réveiller et qui, sur un
  téléphone muet, ne réveille pas, ment une seule fois — la nuit qui compte.
  D'où la position centrale : le SMS et l'appel vocal restent les canaux de
  premier rang, l'application les complète et ne les remplace jamais.

  L'application qu'on n'a pas ouverte depuis huit mois. C'est la situation
  normale de ce produit, et celle qu'aucun cahier des charges n'écrit. Sept
  exigences pour ce seul moment : jeton renouvelé silencieusement, notification
  d'essai pilotée par les campagnes de préparation, aucun écran d'accueil entre
  la notification et la réponse, ouverture à froid en trois secondes.

  Le téléphone n'est pas une source de vérité. La file hors ligne transporte
  une intention ; elle ne calcule aucune empreinte et n'attribue aucune
  séquence. Un appareil qui numéroterait ses propres événements ouvrirait la
  brèche par laquelle la boîte noire perdrait toute valeur probante.

  Ce qu'on refuse, dit aussi clairement que ce qu'on prend. Position en
  continu, carnet d'adresses, télémétrie, widgets. Et côté sécurité : ni refus
  sur appareil débridé, ni blocage des captures d'écran — des mesures qui
  gênent les légitimes sans arrêter personne. Ne rien garder au repos est
  assumé comme la mesure principale.

  Une dépendance dont on ne sort pas. Le document chiffre la sortie d'Expo et
  de React Native, puis dit franchement qu'APNs et FCM sont irremplaçables.
  C'est acceptable parce que la notification n'est pas le canal de premier rang
  et ne transporte aucun contenu ; une organisation qui refuse cette
  dépendance conduit sa crise sans l'application, et le produit reste entier.

  Un jalon où l'on peut s'arrêter. M1 livré — être joint, répondre —
  l'application tient sa promesse entière. M2 et M3 ne se justifient que par
  des usages constatés, pas par le sentiment qu'une application doit en faire
  davantage.

Le mode exercice sert de vitrine
  Les magasins exigent un compte de démonstration fonctionnel. Donner accès à
  une vraie crise est exclu. Ce qui avait été construit pour l'entraînement
  répond exactement à ce besoin, sans exposer personne.

Frère jumeau du document principal
  Même feuille de style, mêmes familles de caractères, même vocabulaire de
  composants. Deux règles ajoutées à la famille « tag », suivant le motif
  existant et ses jetons : les verdicts des tableaux se lisent d'un coup d'œil
  au lieu d'être une colonne de texte.

Publié comme artefact, éprouvé dans les deux thèmes.

Signed-off-by: Kourser <contact@kourser.bzh>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>