Une application mobile à l'E6 et à l'E7 SLAM

À l'E6 SLAM, une application mobile apporte la situation « code exécuté sur un terminal mobile » de l'annexe II.E et se prête bien aux évolutions demandées pendant l'heure de réalisation ; à l'écrit E7 SLAM, l'application mobile revient sous l'angle de la sécurité : stockage des secrets, biométrie et RGPD, communications, journalisation. Ce chapitre prépare les deux : présenter ton application à l'E6, préparer l'environnement de l'heure de réalisation, traiter une évolution complète de bout en bout, puis reconnaître et rédiger les réponses aux questions mobiles de l'E7. Le déroulement des épreuves est détaillé dans les cours Épreuve E6 SLAM et Épreuve E7 SLAM.

L'application mobile dans tes réalisations d'E6

Une réalisation mobile convaincante pour la commission a les mêmes qualités qu'une autre réalisation : une base relationnelle avec des contraintes, des rôles, des règles de gestion, de quoi faire évoluer. Elle y ajoute des points que la commission regarde en particulier :

Sur la fiche descriptive de la réalisation, cite les technologies avec leurs versions : « React Native 0.88 avec Expo SDK 58 et Expo Router, TypeScript ; API Node.js 24 et Express 5 ; MySQL 8.4 ; Jest et React Native Testing Library ; Expo Build pour l'APK de recette ». Sans versions, la commission ne peut pas vérifier la conformité de ton environnement (le dossier E6).

Préparer l'environnement de l'heure de réalisation

Pendant l'heure de réalisation, tu n'as pas le temps de déboguer un réseau ou d'attendre une compilation. Vérifie, la veille et en arrivant :

• l'API démarre en une commande, sa base de démonstration est remplie, et elle est joignable depuis l'émulateur (10.0.2.2) ou le téléphone ;
• l'émulateur Android est créé, démarre, et l'application s'y ouvre avec npx expo start puis a ;
• Expo Go, sur le téléphone, a le même SDK que le projet ; sinon, un development build est déjà installé ;
• le mode tunnel (npx expo start --tunnel) fonctionne, en secours si le réseau de la salle isole les appareils ;
• l'APK de recette est installé, et appelle une API en HTTPS ;
• npm test passe, npx tsc --noEmit ne signale rien ;
• le dépôt Git est propre, sur la bonne branche ;
• tu sais montrer l'écran du téléphone à la commission : l'émulateur sur ton écran, ou une recopie de l'écran du téléphone sur l'ordinateur (scrcpy, un outil libre, le fait pour Android par USB).

L'émulateur est souvent plus sûr que le téléphone pour l'épreuve : il ne dépend pas du Wi-Fi de la salle, et la commission voit l'écran sans se pencher sur ton téléphone.

Les évolutions types sur une application mobile

Les besoins exprimés par la commission touchent rarement une seule couche. Sur une application mobile reliée à une API, une évolution traverse souvent toute la pile.

La méthode reste celle de l'épreuve : le vital d'abord, de bout en bout, testé ; le confort ensuite (l'heure de réalisation). Pour une évolution qui traverse la pile, avance de la base vers l'écran : chaque couche se vérifie avant de passer à la suivante (la requête SQL dans le client MySQL, la route avec curl, puis l'écran).

Cas corrigé : ajouter un commentaire à un frais

Besoin exprimé par la commission. Les comptables refusent souvent des frais faute d'explication. Le visiteur doit pouvoir ajouter, depuis l'application mobile, un commentaire facultatif de 200 caractères au plus à un frais hors forfait (« Repas avec le Dr Morel, cardiologue »). Le commentaire apparaît dans le détail de la fiche.

1. La base. Une colonne facultative :

ALTER TABLE frais_hors_forfait ADD COLUMN commentaire VARCHAR(200) NULL;

2. L'API. Dans l'API du cours Node.js (validation Zod), le schéma Zod de création gagne un champ facultatif, le dépôt l'enregistre avec une requête préparée, et la lecture d'une fiche le renvoie.

// src/schemas/fiches.schemas.js
export const schemaFraisHorsForfait = z.strictObject({
  date: z.iso.date(),
  libelle: z.string().trim().min(3).max(100),
  montant: z.number().positive().max(5000).multipleOf(0.01),
  commentaire: z.string().trim().max(200).nullish(), // absent, null, ou 200 caractères au plus
});

// src/depots/fiches.depot.js
export async function ajouterFraisHorsForfait(id, { date, libelle, montant, commentaire }) {
  const texte = commentaire || null; // absent, null ou vide après trim : NULL en base
  const [resultat] = await pool.execute(
    'INSERT INTO frais_hors_forfait (id_fiche, date_frais, libelle, montant, commentaire) VALUES (?, ?, ?, ?, ?)',
    [id, date, libelle, montant, texte],
  );
  return { id: resultat.insertId, date, libelle, montant, justificatif: false, commentaire: texte };
}

Dans trouverDetail, le SELECT des frais hors forfait ajoute la colonne commentaire. nullish() accepte un champ absent ou null : une ancienne version de l'application, qui n'envoie pas le champ, continue de fonctionner.

Vérifie avec curl avant de toucher à l'application (tester une API).

3. Les types du client d'API, dans api.ts :

export type FraisHorsForfait = { id: number; date: string; libelle: string; montant: number; justificatif: boolean; commentaire: string | null };
export type NouveauFrais = { date: string; libelle: string; montant: number; commentaire?: string };

4. La validation locale, dans validation.ts. SaisieFrais gagne commentaire: string, Frais gagne commentaire?: string, et validerFrais se termine ainsi :

  const commentaire = saisie.commentaire.trim();
  if (commentaire.length > 200) erreurs.commentaire = '200 caractères au maximum.';

  if (Object.keys(erreurs).length > 0) return { erreurs };
  const frais: Frais = { date: saisie.date, libelle, montant: montant as number };
  if (commentaire) frais.commentaire = commentaire;
  return { frais, erreurs };

Un commentaire vide ou fait d'espaces n'est pas envoyé : le champ reste absent, et l'API enregistre NULL. Comme commentaire devient obligatoire dans SaisieFrais, les appels existants à validerFrais, dans l'écran et dans les tests, reçoivent commentaire: ''.

5. L'écran, dans le formulaire « Nouveau frais » : l'état initial reçoit commentaire: '', et un champ de plusieurs lignes s'ajoute :

<Champ
  libelle="Commentaire (facultatif)"
  value={saisie.commentaire}
  onChangeText={modifier('commentaire')}
  erreur={erreurs.commentaire}
  multiline
  maxLength={200}
/>

Dans le détail de la fiche, sous le libellé : {item.commentaire && <Text style={styles.date}>{item.commentaire}</Text>}.

6. La file hors ligne. Un frais saisi sans réseau doit garder son commentaire. C'est l'oubli classique : tout marche en ligne, et le commentaire disparaît des frais saisis dans le train. Dans db.ts, la table SQLite locale passe à la version 2 du schéma, et la file prend la colonne :

// Dans migrer(), après le bloc de la version 1
if (version < 2) {
  await db.execAsync(`
    ALTER TABLE frais_en_attente ADD COLUMN commentaire TEXT;
    PRAGMA user_version = 2;
  `);
}

// Le commentaire lu en base vaut NULL quand il n'y en a pas
export type FraisEnAttente = Omit<Frais, 'commentaire'> & {
  commentaire: string | null; cle: string; idFiche: number; photo: string | null;
};

export async function mettreEnAttente(idFiche: number, frais: Frais, cle: string, photo: string | null) {
  const db = await ouvrirBase();
  await db.runAsync(
    'INSERT INTO frais_en_attente (cle, id_fiche, date, libelle, montant, commentaire, photo) VALUES (?, ?, ?, ?, ?, ?, ?) ON CONFLICT (cle) DO NOTHING',
    [cle, idFiche, frais.date, frais.libelle, frais.montant, frais.commentaire ?? null, photo],
  );
}

export async function lireEnAttente(): Promise<FraisEnAttente[]> {
  const db = await ouvrirBase();
  return db.getAllAsync<FraisEnAttente>(
    'SELECT cle, id_fiche AS idFiche, date, libelle, montant, commentaire, photo FROM frais_en_attente ORDER BY rowid',
  );
}

Et synchroniser doit transmettre le commentaire (avec import type { NouveauFrais } from './api') :

const nouveau: NouveauFrais = { date: f.date, libelle: f.libelle, montant: f.montant };
if (f.commentaire) nouveau.commentaire = f.commentaire; // NULL en base : champ absent
const cree = await api.ajouterFrais(f.idFiche, nouveau, f.cle);

Le frais renvoyé par la file est ainsi identique à celui qu'aurait envoyé le formulaire : même corps, donc même empreinte pour la clé d'idempotence. Trois fichiers à toucher pour la file : db.ts (migration, type, insertion, lecture), synchro.ts, et côté API le schéma qui accepte l'absence de commentaire. Les tests de synchroniser du chapitre 11 ajoutent alors commentaire: null aux frais qu'ils fabriquent.

7. Le test, dans validation.test.ts :

it('accepte un commentaire facultatif et refuse plus de 200 caractères', () => {
  const base = { date: '2026-10-14', libelle: 'Repas', montant: '23,50' };
  expect(validerFrais({ ...base, commentaire: '  ' }, '2026-11-02').frais).toEqual({ date: '2026-10-14', libelle: 'Repas', montant: 23.5 });
  expect(validerFrais({ ...base, commentaire: ' Client Dr Morel ' }, '2026-11-02').frais?.commentaire).toBe('Client Dr Morel');
  expect(validerFrais({ ...base, commentaire: 'x'.repeat(201) }, '2026-11-02').erreurs.commentaire).toBeDefined();
});

Le vital de ce besoin : la colonne, l'API, le champ du formulaire, l'affichage dans le détail. Le confort : un compteur de caractères sous le champ, la colonne dans la file hors ligne si le temps manque (à signaler à la commission comme limite connue, plutôt qu'à cacher).

Les questions d'application mobile à l'E7

Le sujet de cybersécurité SLAM de 2024 (alors épreuve E6, unité U6, devenue E7 en 2025) consacrait tout un dossier à l'application mobile d'un service d'incendie et de secours (le corrigé). Ses questions reviennent sous d'autres formes d'une session à l'autre :

Les sujets donnent le code dans le langage de l'application étudiée, souvent du Java ou du Kotlin pour Android, parfois du C#. Tu n'as pas à connaître ce langage : les noms des fonctions (onAuthenticationSucceeded, execSQL, getWritableDatabase) et la logique suffisent, et les mêmes principes s'appliquent qu'en TypeScript (lire du code sur papier). Rédige chaque réponse en situant le problème, en le nommant avec le vocabulaire juste (stockage non sécurisé, client public, catégorie particulière de données), en l'expliquant dans le contexte du sujet, puis en corrigeant.

async function seConnecter(matricule: string, motDePasse: string) {
  const reponse = await fetch(`${URL_API}/connexion`, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ matricule, motDePasse }),
  });
  const { jeton } = await reponse.json();
  await Storage.setItem('jeton', jeton);              // kv-store
  await Storage.setItem('motDePasse', motDePasse);    // pour la reconnexion automatique
}

await db.execAsync(`INSERT INTO connexion (resultat, message) VALUES ('${resultat}', '${message}')`);