2010 m’a amené pas mal plus loin que prévu. J’ai commencé l’année à Jacksonville comme chef d’équipe chez Taleo. Depuis avril, je vis à Paris et je travaille comme architecte de solutions chez NOVIPRO, où je suis exposé à des appareils Windows durcis pour des environnements de défense. Le changement de lieu a surtout changé les pannes que je dois imaginer.

Dans un service en ligne, la requête traverse le DNS, le répartiteur, l’application, la base et les dépendances. Sur un terminal terrain, elle peut ne jamais quitter l’appareil parce que la radio a disparu. Ces deux mondes partagent une leçon : l’écran ne dit pas où l’opération est rendue.

Trois trajets techniques qui résument mon année

Pour une recherche SaaS, je veux pouvoir suivre :

navigateur → frontal web → service applicatif → base de données → réponse

Chaque étape doit produire une durée et un identifiant commun. Un serveur qui répond au ping ne prouve ni que l’authentification fonctionne ni que la requête SQL termine. Les percentiles de temps de réponse, les erreurs par fonction et une sonde extérieure décrivent mieux le service vécu.

Pour une inspection mobile, le trajet est différent :

formulaire → stockage local → file de synchronisation → API → transaction serveur

L’écriture locale protège le travail quand la connexion tombe. Un identifiant d’opération empêche le doublon si l’appareil renvoie après avoir perdu la confirmation. Une version permet de détecter qu’un collègue a modifié le même dossier entre-temps. Le mode hors ligne devient ainsi un protocole, pas une simple case dans les exigences.

Avec Kinect, le corps traverse encore une autre chaîne :

infrarouge → carte de profondeur → squelette estimé → geste reconnu → action rendue

Le filtrage réduit le bruit, mais ajoute du délai. L’absence de bouton enlève le retour tactile; l’interface doit donc confirmer ce qu’elle a compris. Un geste caché par le torse ou hors du champ doit être traité comme une mesure incertaine.

L’architecture commence par la contrainte dominante

Ces systèmes n’ont pas la même priorité. Pour les comparer, je garderais quatre questions :

1. Quel état ne peut pas être perdu? La transaction client, l’inspection locale ou la progression du joueur.
2. Quelle dépendance va probablement manquer? Une base lente, un réseau absent ou une articulation invisible.
3. Quelle confirmation comprend l’utilisateur? Résultat affiché, reçu de synchronisation ou feedback immédiat.
4. Quel retour arrière existe? Reprise de transaction, renvoi idempotent ou annulation du geste.

L’iPad, les téléphones intelligents et les terminaux durcis poussent l’informatique hors du bureau. La batterie impose des intervalles de synchronisation, le soleil impose du contraste et un doigt ganté impose de grandes cibles. La sécurité voyage elle aussi : stockage chiffré, verrouillage, révocation de l’appareil et jetons qui expirent. Une commande d’effacement à distance ne suffit pas si le terminal reste déconnecté.

Le GPS illustre une contrainte moins visible. Une coordonnée permet de guider; une série horodatée permet de reconstruire une routine. L’architecture doit distinguer le calcul nécessaire, la transmission et la conservation. Le fait de pouvoir enregistrer la position n’explique pas pourquoi on devrait la garder.

Je ne retiens donc pas une technologie gagnante de 2010. Je retiens une façon de dessiner : lister le trajet réel, l’état détenu par chaque composante, la preuve de succès et le comportement quand la prochaine dépendance manque. Pour mon prochain projet terrain, je ferais cet exercice avant la première maquette; le petit écran révèle seulement les choix qu’on aurait dû faire de toute façon.