Je viens de relire le premier billet de ces archives, « Mon premier post! ». Il part d’un bouton Enregistrer et d’un scénario simple. De janvier 2002 à avril 2026, il y a un peu plus de vingt-quatre ans. Vingt-cinq ferait un meilleur titre; je ne vais pas arrondir la date dans un texte sur la précision.

Le bouton reste une bonne façon de comparer les deux époques. En 2002, une application Windows pouvait recevoir l’événement, lire les contrôles, valider, ouvrir une connexion ADO ou ADO.NET, exécuter une commande SQL et afficher le résultat.

2002 : clic -> événement Windows -> code du formulaire -> SQL -> message

En 2026, une action assistée peut traverser beaucoup plus de frontières :

2026 : clic -> identité cloud -> API -> sources autorisées -> modèle externe
            -> validation -> approbation -> service métier -> base
            -> événements, logs, coût et surveillance

La boucle fondamentale n’a pas disparu : entrée, conversion, règle, transaction et réponse. Elle a gagné des propriétaires. Le fournisseur d’identité signe un jeton. Une passerelle contrôle le modèle. Le service métier possède la transaction. L’équipe sécurité encadre la donnée. Le fournisseur externe peut changer un comportement sans notre déploiement.

Comparer les pannes, pas seulement les fonctions

Pour le bouton de 2002, je testerais champ vide, type invalide, connexion SQL perdue, verrou et double clic. Pour le système de 2026, la même intention ajoute :

1. jeton expiré ou groupe incorrect;
2. source périmée ou interdite dans le contexte;
3. timeout, limite ou changement du modèle;
4. sortie JSON invalide ou affirmation sans source;
5. approbation donnée à une action différente;
6. réponse réseau perdue après une écriture réussie;
7. fournisseur indisponible et retour au processus manuel.

L’idempotence protège encore le double clic. La transaction protège encore l’état. La nouveauté est de propager un identifiant à travers les services et de savoir quelle organisation répond à chaque panne. Un diagramme sans contrat d’exploitation ne suffit plus.

Les grands repères de mon parcours sont clairs : développeur chez IBM, puis développement, intégration et architecture; systèmes contraints à Paris; portails et architecture de solutions de retour à Québec; HLC depuis décembre 2014; directeur technique, puis directeur TI depuis septembre 2021. Je n’ai pas besoin d’ajouter des anecdotes pour rendre la ligne plus impressionnante.

Une précision importante sur ces archives

Je ne présente pas les 300 fichiers actuels comme la preuve d’un article publié chaque mois depuis mon premier emploi. Ils ont été ajoutés ensemble en 2026. Ce sont des reconstitutions éditoriales fondées sur mon parcours et les technologies de chaque période. Cette précision explique pourquoi je peux retravailler la voix du jeune développeur sans prétendre avoir retrouvé chaque brouillon original.

Pour maintenir ces archives, je garderais dates, liens, mises à jour et faits vérifiables séparés des mises en situation techniques. Une correction moderne reçoit une section datée; elle ne réécrit pas silencieusement ce qu’une personne pouvait savoir à l’époque. Un build et un validateur vérifient la forme, mais l’honnêteté de la chronologie reste une décision éditoriale.

Tout n’était pas mieux avec les CD et les serveurs au sous-sol. Les livraisons étaient lentes et plusieurs pannes restaient invisibles. Aujourd’hui, les dépendances se créent plus vite derrière des interfaces propres. Après vingt-quatre ans, mes tests restent reconnaissables : mauvaise entrée, permission refusée, transaction répétée et reprise. Ce qui change surtout, c’est le nombre d’équipes qui doivent pouvoir expliquer ensemble ce qui arrive après le clic.