Je voulais faire un palmarès techno de 2004, choisir quelques produits et décider lequel gagne. En relisant mes billets, une idée plus utile ressort : chaque système transforme des observations imparfaites en un état auquel l’entreprise finit par faire confiance.

La RFID lit un signal radio, pas un mouvement de stock. Le CRM rapproche des fiches, pas des personnes avec une certitude parfaite. Le rapport additionne des lignes selon une définition, pas « les ventes » dans l’absolu. Le jeu reçoit des commandes en retard et fabrique pourtant un monde autoritaire. Dans chaque cas, la qualité vient des règles entre l’entrée brute et l’état officiel.

Système	Entrée brute	État officiel	Contrôle essentiel
RFID	réponses répétées d’étiquettes	entrée/sortie de stock	fenêtre, direction, déduplication
CRM	fiches de plusieurs sources	identité client liée	score, provenance, revue humaine
Reporting	transactions et statuts	indicateur publié	grain, formule, réconciliation
Jeu réseau	commandes numérotées	monde du serveur	validation, tick, correction
Autorisation	identité et SID de groupes	opération permise/refusée	rôle, ressource, règle côté service

Ce tableau change ma façon de concevoir une intégration. Je ne veux plus une flèche sans contrat entre deux boîtes. Je veux savoir quelle donnée traverse, qui lui attribue un identifiant, ce qui arrive à un doublon, quelle horloge date l’événement et à quel moment on peut dire qu’il est commis.

Un workflow qui rassemble l’année

Imaginons une réception d’équipement identifiée par RFID et visible dans un rapport :

1. le lecteur capte plusieurs fois l’EPC E200...42;
2. le middleware regroupe les lectures pendant deux secondes;
3. deux antennes confirment une direction vers l’intérieur;
4. il publie ENTREE-8471 avec EPC, portail et heure;
5. le service vérifie que l’EPC est attendu et que ENTREE-8471 est nouveau;
6. une transaction ajoute le mouvement et met à jour le stock;
7. une extraction nocturne charge le fait dans le reporting;
8. le rapport montre l’heure de sa dernière extraction.

Si le réseau tombe après l’étape 4, le middleware garde l’événement et le renvoie avec le même identifiant. Si le service valide l’étape 6 mais que l’accusé se perd, la contrainte unique empêche un deuxième mouvement. Si l’étiquette est lue au mauvais portail, la règle métier rejette l’événement et le conserve dans une file de revue. Si l’ETL échoue, le rapport reste sur le dernier lot complet et annonce qu’il est périmé au lieu d’afficher un demi-total.

Les permissions traversent le même flux. Le compte du lecteur peut publier des observations, pas corriger le stock. Le service possède la transaction. Le rapport expose des agrégats à plus de monde que les détails. Les logs partagent un corr=ENTREE-8471 mais ne recopient pas toutes les données client. Chaque composante reçoit seulement le droit et l’information nécessaires.

Le matériel reste présent derrière les abstractions. Le service vit sur une machine alimentée et refroidie. Ses fichiers peuvent être sur un LUN de SAN dont le cache et les chemins doivent tenir. Un snapshot rapide n’est pas une copie hors site. Restaurer l’application demande la base, les files encore en attente, les clés et une procédure testée dans le bon ordre.

Je vois maintenant une revue technique assez courte à appliquer avant une démo :

• dessiner les composantes et les frontières réseau;
• nommer l’état autoritaire et les identifiants;
• écrire une règle pour doublon, retard et entrée invalide;
• limiter chaque permission à un rôle et une opération;
• calculer volume, latence et conservation;
• couper une dépendance puis observer la reprise;
• restaurer une copie et réconcilier le résultat.

Ça ne retire rien au wow factor du stylet, de la RFID ou du multijoueur. Au contraire, comprendre le capteur, les files et les corrections rend la réussite plus impressionnante. En 2005, je veux continuer à essayer les nouveautés, mais avec un crayon prêt à dessiner ce qui se passe entre le geste et la donnée officielle.