<h2>1. Partir du problème réel</h2><p>Le sujet « Versionner une application pour que chaque livraison soit traçable » devient utile lorsqu'on le rattache à une contrainte mesurable. Ici, l'angle choisi est SemVer, changelog, migration et SHA-256. Avant de modifier le code, je note le symptôme, le contexte, le volume de données, le comportement attendu et la manière de vérifier le résultat. Cette discipline évite les corrections qui déplacent simplement le problème ailleurs.</p><p>Dans un projet métier, la bonne solution n'est pas nécessairement la plus sophistiquée. Elle doit surtout rester compréhensible au prochain incident. Je privilégie donc des composants courts, des états explicites, des erreurs traçables et une séparation nette entre interface, logique métier et accès aux données.</p><h2>2. Concevoir le flux avant l'écran</h2><p>Je dessine d'abord le chemin de la donnée : origine, validation, stockage, transformation, synchronisation et affichage. Pour SemVer, changelog, migration et SHA-256, chaque étape doit pouvoir échouer sans laisser une donnée dans un état ambigu. C'est aussi là que je décide où placer les identifiants stables, les horodatages, les tentatives et les journaux.</p><blockquote>Une interface rapide ne compense pas un flux de données imprécis. L'utilisateur ressent immédiatement les doublons, les blocages et les résultats manquants.</blockquote><h2>3. Exemple minimal</h2><p>L'extrait suivant ne représente pas une application complète; il montre plutôt la forme du contrat que je cherche : lisible, testable et sans effet caché.</p><pre><code>Décision → hypothèse → mesure → résultat → prochaine action.</code></pre><p>Le point important est de garder le code d'infrastructure remplaçable. Une API, une base locale, un hébergement ou un SDK peuvent évoluer. Les règles métier doivent rester testables sans dépendre de l'écran ou d'un fournisseur précis.</p><h2>4. Gérer les cas difficiles</h2><p>Je teste ensuite les scénarios qui cassent les démonstrations parfaites : réseau lent, doublon, deux utilisateurs sur la même donnée, retour arrière, caractère arabe, écran étroit, liste très longue, redémarrage de l'application et serveur temporairement indisponible. C'est souvent dans ces cas que la qualité d'architecture devient visible.</p><p>Pour éviter le comportement “ça marche chez moi”, chaque action importante produit un résultat exploitable : succès confirmé, erreur classée, nouvelle tentative planifiée ou conflit à résoudre. L'absence de réponse n'est jamais considérée comme un succès.</p><h2>5. Mesurer avant d'optimiser</h2><p>Sur Versionner une application pour que chaque livraison soit traçable, j'observe au minimum le temps de réponse, le nombre de requêtes, les erreurs, les éléments chargés et les opérations répétées. Une optimisation doit réduire un coût précis. Par exemple, limiter une carte à la zone visible ou ajouter un index adapté vaut mieux qu'un cache global ajouté sans diagnostic.</p><h3>Checklist de vérification</h3><ul><li>Le résultat est-il exact avant d'être rapide ?</li><li>Le flux supporte-t-il une nouvelle tentative ?</li><li>Les permissions sont-elles appliquées côté serveur ?</li><li>Le journal permet-il de comprendre une anomalie sans reproduire le poste utilisateur ?</li><li>Le mobile et la tablette conservent-ils la priorité au contenu utile ?</li></ul><h2>6. Ce que je garderais en production</h2><p>Je garde une solution lorsque son comportement est prévisible et documenté. Pour SemVer, changelog, migration et SHA-256, cela signifie généralement un contrat d'entrée strict, un stockage cohérent, des identifiants stables, une stratégie d'erreur explicite et un test qui rejoue le scénario critique. Ensuite seulement j'ajoute les optimisations visuelles.</p><p>La meilleure évolution suivante consiste à automatiser une vérification de non-régression. Le but n'est pas d'accumuler des couches techniques, mais de pouvoir changer une partie du système sans casser silencieusement les autres.</p>