Le jour de l'entretien

Savoir n'est pas suffisant : il faut le montrer en une heure, sous le regard de quelqu'un, parfois en anglais, parfois en codant en direct. Ce chapitre donne une méthode pour chaque format : system design mobile, live coding, revue de code, questions comportementales, discussion sur le TJM. Il se termine par un entretien blanc complet.

Le déroulé typique d'une mission en régie

Au Maroc, les banques, opérateurs télécoms et administrations recrutent souvent leurs consultants mobiles par l'intermédiaire d'un intégrateur IT (ESN, société de services). Le processus a généralement trois ou quatre étapes :

L'intégrateur n'est pas un simple intermédiaire : il vous présente au client et engage sa réputation. Soignez cet échange, soyez précis sur vos disponibilités et cohérent sur votre TJM. Demandez-lui ce qu'il sait du client : stack, taille de l'équipe, format de l'entretien, langue, présence d'un test. Ces informations valent beaucoup.

Préparation logistique

• Visio : outil installé et testé la veille (le client impose souvent le sien), caméra à hauteur des yeux, lumière de face, micro-casque, connexion filaire ou partage de connexion en secours.
• Partage d'écran : un seul écran partagé, notifications coupées, onglets et fichiers personnels fermés, police de l'IDE agrandie (16 à 18 pt).
• IDE prêt : un projet Flutter vierge qui compile, avec flutter_riverpod, http ou dio, mocktail déjà ajoutés ; un émulateur ou un appareil déjà lancé ; flutter doctor sans erreur ; SDK à jour (3.47).
• Assistant IA : désactivé si on vous le demande, et de préférence désactivé par défaut. Une suggestion qui apparaît pendant un live coding sans IA met tout le monde mal à l'aise.
• Documents : votre CV tel que l'intégrateur l'a envoyé (il est parfois reformaté), la fiche de poste, vos six histoires, vos questions pour le client.

System design mobile : la méthode

Un exercice de system design teste votre capacité à structurer un problème flou, à faire des choix et à les justifier. Il n'y a pas de solution unique. Le piège principal est de dessiner des boîtes tout de suite. Suivez ces étapes et annoncez-les :

Étude 1 : « Concevez une app e-wallet »

Clarification. Particuliers et commerçants. Parcours : inscription avec KYC, consultation du solde et de l'historique, transfert à un bénéficiaire, paiement par QR code, paiement de factures. Hors périmètre : crédit, épargne. Non fonctionnel : sécurité maximale (argent réel, régulateur), disponibilité, appareils Android d'entrée de gamme, arabe et français, réseau mobile instable. Estimation : un million d'utilisateurs, pic à la fin du mois ; sur l'appareil, quelques centaines de transactions en cache.

• Flux de données : Riverpod. Le solde et l'historique sont des AsyncNotifier ; le transfert est un Notifier à états (saisie, confirmation, envoi, résultat). Après un transfert réussi, on invalide le solde et la première page de l'historique.
• API : REST avec pagination par curseur ; montants en centimes (int) ; Idempotency-Key obligatoire sur les transferts et paiements, conservée tant que l'opération n'est pas confirmée, pour qu'un retry réseau ne débite pas deux fois ; erreurs typées (INSUFFICIENT_FUNDS...).
• Stockage : tokens dans le stockage sécurisé (Keychain, Keystore) ; cache de l'historique en base locale chiffrée, purgé à la déconnexion ; aucune opération financière hors ligne (on affiche le cache en lecture seule, avec la date de dernière mise à jour).
• Sécurité : OAuth2 avec PKCE ou login propriétaire, access token de quelques minutes, refresh token rotatif avec file d'attente pour les requêtes concurrentes ; biométrie pour déverrouiller l'app et confirmer un transfert au-delà d'un seuil ; SSL pinning avec plan de rotation ; détection root/jailbreak et attestation (Play Integrity, App Attest) remontées au serveur, qui décide ; masquage de l'écran dans le sélecteur d'apps ; obfuscation ; MASVS comme référentiel.
• Observabilité : crashs sans PII, métriques de parcours (taux d'échec d'un transfert), corrélation des requêtes avec un identifiant transmis au backend.
• Tests et livraison : unitaires sur les règles de montant et les états, widget sur le parcours de transfert, intégration contre un backend simulé ; CI avec builds signés par flavor ; déploiement progressif ; version minimale côté serveur pour forcer la mise à jour.
• Compromis : pas de transfert hors ligne (risque de double dépense, solde non garanti) ; pinning contre souplesse de rotation des certificats ; biométrie seule insuffisante pour les gros montants (ajouter un OTP).

Étude 2 : « Concevez une app terrain hors ligne pour des commerciaux »

Clarification. 500 commerciaux d'une entreprise de distribution, en zones rurales sans réseau pendant des heures. Parcours : tournée du jour, fiche client, prise de commande avec catalogue et prix, encaissement, photos de linéaire, signature. Non fonctionnel : tout doit fonctionner hors ligne ; synchronisation fiable ; appareils fournis et gérés par MDM ; données commerciales sensibles ; batterie sur une journée. Estimation : 2 000 clients et 5 000 références par commercial, quelques dizaines de commandes par jour, photos de 300 Ko.

• Principe : l'UI ne lit que la base locale (offline-first). Le réseau ne sert qu'à synchroniser. Une commande est écrite localement avec un statut pending et une entrée d'outbox dans la même transaction.
• Pull : synchronisation initiale lourde (catalogue, clients de la zone) en Wi-Fi au dépôt, puis deltas par curseur. Gérer les suppressions (tombstones).
• Push : opérations envoyées dans l'ordre, par lots, chacune avec une clé d'idempotence ; photos envoyées séparément, en dernier, reprises en cas de coupure.
• Conflits : les commandes sont des créations (pas de conflit) ; pour une fiche client modifiée des deux côtés, règle explicite par champ (serveur prioritaire pour les données de référence, terrain prioritaire pour les coordonnées relevées), et journal des conflits visible du superviseur. Le prix est recalculé et validé par le serveur, qui peut rejeter une commande : l'app doit afficher ce rejet.
• Sécurité : base chiffrée (clé dans le Keystore ou le Keychain), effacement à distance par le MDM, verrouillage par code ou biométrie, multi-tenant isolé par une base par compte.
• Batterie et performance : synchronisation déclenchée par événements plutôt qu'en continu, index sur les colonnes de recherche, pagination locale, parsing des gros lots dans un isolate.
• Observabilité : âge de la dernière synchronisation réussie, taille de l'outbox, nombre d'échecs, remontés au serveur ; un écran « état de la synchronisation » pour le support.
• Compromis : prix potentiellement périmés hors ligne (afficher la date du catalogue, validation finale serveur) ; taille de la base contre exhaustivité du catalogue ; complexité de la synchronisation contre simplicité d'un mode en ligne.

Live coding : la méthode

1. Reformuler l'énoncé avec vos mots. Cela évite de coder la mauvaise chose.
2. Poser des questions : données d'entrée, cas limites, packages autorisés, est-ce qu'on veut des tests, combien de temps.
3. Annoncer le plan en trois ou quatre étapes avant de taper.
4. Coder simple d'abord : une version qui fonctionne, puis améliorer. Une solution élégante inachevée vaut moins qu'une solution simple qui tourne.
5. Parler en codant : ce que vous faites et pourquoi. Le silence est le pire signal. Si vous bloquez, dites-le et dites ce que vous essayez.
6. Tester : lancer l'app, essayer un cas limite, écrire un test si le temps le permet. Terminer par ce que vous feriez avec plus de temps.

Six exercices classiques

Revue de code à faire

Format fréquent : on vous montre un extrait et on vous demande ce que vous changeriez. Lisez l'extrait ci-dessous, chronomètre lancé (10 minutes), et notez tous les problèmes avant d'ouvrir la correction.

import 'dart:convert';

import 'package:flutter/material.dart';
import 'package:http/http.dart' as http;

class TransferScreen extends StatefulWidget {
  TransferScreen({required this.userId});
  final String userId;

  @override
  State<TransferScreen> createState() => _TransferScreenState();
}

class _TransferScreenState extends State<TransferScreen> {
  final amountController = TextEditingController();
  double balance = 0;
  List beneficiaries = [];
  bool loading = false;
  static const apiKey = 'sk_live_51H8xQ2eZvKYlo2C';

  Future<void> loadBalance() async {
    final res = await http.get(
      Uri.parse('https://api.example.com/wallet?key=$apiKey'),
    );
    setState(() {
      balance = jsonDecode(res.body)['balance'];
    });
  }

  Future<void> send() async {
    setState(() => loading = true);
    final amount = double.parse(amountController.text);
    try {
      await http.post(
        Uri.parse('https://api.example.com/transfers'),
        body: jsonEncode({'userId': widget.userId, 'amount': amount}),
      );
    } catch (e) {}
    setState(() => loading = false);
    Navigator.of(context).pop();
  }

  @override
  Widget build(BuildContext context) {
    loadBalance();
    return Scaffold(
      appBar: AppBar(title: Text('Transfert')),
      body: Column(
        children: [
          Text('Solde : ${balance.toStringAsFixed(2)} MAD'),
          TextField(
            controller: amountController,
            keyboardType: TextInputType.number,
          ),
          ListView(
            children: beneficiaries
                .map((b) => ListTile(title: Text(b['name'])))
                .toList(),
          ),
          ElevatedButton(
            onPressed: loading ? null : send,
            child: loading ? CircularProgressIndicator() : Text('Envoyer'),
          ),
        ],
      ),
    );
  }
}

Questions comportementales : la méthode STAR

Les questions « Parlez-moi d'une fois où... » évaluent votre comportement passé, meilleur indicateur de votre comportement futur. La méthode STAR donne une structure de 90 secondes à 2 minutes :

Erreurs courantes : une situation de deux minutes et une action de vingt secondes ; « nous » partout au lieu de « je » ; une histoire sans résultat ; un échec qui n'en est pas un (« je suis trop perfectionniste »).

Huit questions classiques et la structure attendue

Six histoires réutilisables

Une même histoire bien préparée répond à plusieurs questions. Préparez-en six, vraies, et entraînez-vous à les raconter. Personne ne peut les écrire à votre place : voici le canevas à remplir pour chacune.

Freelance et TJM

Un profil freelance soulève deux inquiétudes chez le client : la stabilité (allez-vous partir au bout de trois mois ?) et l'intégration dans l'équipe. Présentez votre parcours comme une suite de missions choisies, avec des durées, des responsabilités et des résultats. Insistez sur votre engagement pour la durée de la mission.

• Ne vous dévalorisez pas : pas de « je suis un peu rouillé sur... » non sollicité, pas d'excuse sur une période sans mission. Une phrase factuelle suffit.
• N'annoncez pas votre plancher : donnez un TJM cible cohérent avec le marché et votre niveau, et laissez la négociation à l'étape prévue (souvent avec l'intégrateur, pas avec le client technique).
• Avec le client final, le TJM est rarement abordé : si c'est le cas, renvoyez poliment vers l'intégrateur.
• Cohérence : le TJM annoncé à l'intégrateur doit être le même d'un échange à l'autre.

Questions à poser au client

Vos questions montrent votre niveau autant que vos réponses. Préparez-en cinq et posez-en deux ou trois :

• Équipe : combien de développeurs mobiles, qui fait le backend, y a-t-il un lead mobile, comment sont réparties les features ?
• CI et qualité : quelle CI, quels tests automatisés, quelle couverture visée, lints imposés ?
• Revue de code : obligatoire, combien de relecteurs, qui valide ?
• Dette : quelle est la plus grosse dette technique de l'app aujourd'hui, et y a-t-il du temps prévu pour la traiter ?
• Release : à quelle fréquence publiez-vous, qui pilote les stores, y a-t-il un comité de mise en production ?
• Politique IA : avez-vous une politique sur les assistants de code, et des outils validés ?
• Travail : présentiel ou hybride, outils de collaboration, horaires de l'équipe, accès VPN depuis l'extérieur ?
• Succès : à quoi reconnaîtrez-vous dans trois mois que la mission est réussie ?

Réponses clés en anglais

Se présenter en 90 secondes : canevas. Remplissez avec vos propres éléments, puis répétez à voix haute jusqu'à le dire sans lire.

Décrire son dernier projet. Structure : what the app does and for whom, team and your role, architecture in three sentences, one hard problem and how you solved it, the result.

Check-list de la veille et du jour J

Rafale de révision : 20 questions, 20 réponses

Questions d'entretien

Exercices

Entretien blanc : 60 minutes

Pas d'étape de fil rouge ici : à la place, un entretien blanc complet. Idéalement avec un pair qui joue le recruteur ; sinon seul, en vous enregistrant et en lisant les questions à voix haute. Respectez les durées.

Grille d'auto-évaluation (notez chaque ligne de 1 à 4 ; 1 = insuffisant, 4 = convaincant) :

Total sur 40. En dessous de 28, retravaillez les deux critères les plus faibles et refaites l'entretien blanc trois jours plus tard avec d'autres sujets. Au-dessus de 32, vous êtes prêt : gardez le rythme avec un exercice sans IA par jour jusqu'à l'entretien.

Quiz

12 questions sur la méthode. Corrigez, relisez les explications, refaites-le 48 h plus tard.

Pour aller plus loin

• Guide d'architecture des apps Flutter
• Offline-first (design patterns Flutter)
• Performance Flutter
• Tests dans Flutter
• Documentation Riverpod
• OWASP Mobile Application Security (MASVS, MASTG)
• Effective Dart