Avant de fermer 2003, je viens de relire les sujets qui m’ont accroché cette année. Ce n’est pas un classement sérieux de l’industrie. C’est la carte des trajets que j’ai enfin commencé à voir sous les interfaces.

Le PC paraît plus mobile et plus visuel, mais chaque expérience dépend d’un pipeline différent :

Expérience visible	Pipeline caché	État fragile
ouvrir l’intranet à distance	Wi-Fi → TCP/IP → VPN → IE → serveur	session et opération en cours
recevoir un document	SMTP → file → boîte → client MIME	version et pièce jointe
importer une photo	capteur → JPEG → carte → disque → catalogue	unique copie et métadonnées
afficher un jeu	entrée → CPU → shaders GPU → tampon → écran	budget de l’image

Le Wi-Fi a été le meilleur rappel que « connecté » n’est pas un état permanent. Le portable s’associe à une borne, obtient une adresse DHCP et partage la radio avec les autres. Une trame perdue est retransmise; TCP ralentit et reprend; l’application voit seulement un délai ou un timeout. Le VPN ajoute du chiffrement et une passerelle, mais ne retire aucun aller-retour.

Je peux chiffrer le problème. Quarante demandes séquentielles de 80 ms coûtent au moins 3,2 secondes. Regrouper les données dans une demande ne rend pas le lien plus rapide; ça arrête simplement de payer la distance quarante fois. En 2004, je veux regarder le nombre d’allers-retours aussi naturellement que le nombre de lignes d’une requête.

Le courriel m’a montré une autre sorte de réseau. SMTP accepte qu’un serveur soit temporairement absent : il conserve le message et réessaie. Cette bonne tolérance aux pannes ne transforme pas le message en ticket. Il manque toujours un état, un responsable et une version de référence. Je vais donc garder le transport asynchrone, puis placer le travail dans une structure qui sait passer de Nouveau à Fermé.

Un exemple qui mélange tout

Imaginons qu’une personne envoie des photos depuis un portable sur Wi-Fi vers un portail interne par VPN :

1. la caméra écrit un JPEG et des métadonnées sur la carte;
2. le PC copie le fichier et calcule une empreinte;
3. IE ouvre une session sur le portail;
4. HTTP découpe le téléversement en paquets TCP;
5. le VPN chiffre et encapsule ces paquets;
6. la borne retransmet les trames radio perdues;
7. le serveur écrit d’abord dans un fichier temporaire;
8. après réception complète, il vérifie taille et type, puis publie une version;
9. l’index de recherche traitera plus tard les métadonnées.

Si le Wi-Fi tombe à l’étape 6, le portail ne doit pas publier le fichier temporaire comme une photo complète. Si la réponse se perd après l’étape 8, un deuxième essai devrait reconnaître la même empreinte plutôt que créer deux documents. Si le nom contient ..\, le serveur ne doit jamais le laisser choisir un chemin arbitraire. Et la version publiée doit avoir des permissions, pas seulement une URL difficile à deviner.

Cette mise en situation relie pas mal toute mon année : représentation source, transport, validation, commit, reprise et visibilité différée. Elle explique aussi pourquoi « ça marche chez moi » est un test très court. Le chemin local évite justement la radio, le tunnel, la concurrence et la reprise.

Les shaders ont fourni le gros wow factor. Un vertex shader transforme les sommets, un pixel shader combine textures et lumière, puis le pipeline recommence avant la prochaine image. Ce qui m’impressionne maintenant n’est pas seulement l’effet; c’est le travail que le moteur ne fait pas : objets hors caméra, détails invisibles, états regroupés. Le même principe vaut pour une application qui ne devrait pas charger 100 000 clients pour montrer 25 lignes.

Mon exercice pour finir l’année sera de dessiner un flux avant de coder : composantes, données persistantes, frontières de sécurité et résultat incertain après une coupure. Ensuite je provoque une panne à une frontière. Une technologie devient vraiment intéressante quand je peux expliquer comment elle reprend, pas seulement quand sa démo réussit.