Solutions Architect

Je commence par séparer ce que la partie prenante demande du problème qu'elle essaie réellement de résoudre, car les deux divergent plus souvent qu'on ne le pense. Je mène des sessions de discovery avec les utilisateurs réels du système, pas seulement le sponsor, et je capture les besoins selon un modèle simple: la capacité business nécessaire, le point de friction actuel, et le résultat mesurable qui prouverait le succès. Je transforme ensuite tout cela en une matrice de traçabilité qui relie chaque besoin business à un composant architectural précis, pour que rien ne soit construit sans justification claire. Pour les exigences non fonctionnelles, je pousse les parties prenantes à me donner des chiffres plutôt que des adjectifs: un temps de réponse défini sous une charge définie plutôt que 'rapide', un standard de conformité nommé plutôt que 'sécurisé'. Je consigne les hypothèses et contraintes dans un architecture decision record avant même de dessiner le premier diagramme, car la plupart des désaccords d'architecture plus tard dans le projet remontent à une hypothèse que personne n'avait écrite. Et je relis toujours l'architecture avec l'équipe technique et la partie prenante d'origine avant de la finaliser, car une conception que seuls les ingénieurs comprennent a déjà échoué à l'étape de traduction.

Les exigences non fonctionnelles sont souvent la première victime d'un délai serré, donc mon rôle est de rendre ce compromis visible plutôt que de le laisser se produire par défaut. Je note chaque exigence selon son impact business et le coût de la corriger plus tard: un contrôle de sécurité coûteux à ajouter après le lancement reste protégé même sous pression, tandis qu'un objectif de performance avec de la marge peut raisonnablement être phasé. Je présente cela comme un menu aux parties prenantes plutôt que comme un veto technique, en détaillant le périmètre complet, ce qu'on peut reporter sans augmenter matériellement le risque, et ce qui ne peut pas bouger sans validation explicite de quelqu'un ayant l'autorité d'accepter ce risque. J'ai vu des équipes abandonner discrètement le chiffrement au repos ou la journalisation d'audit sous pression de délai parce que personne n'avait présenté cela comme une décision nécessitant une validation, et cela ressort des mois plus tard comme un constat de non-conformité bien plus coûteux à corriger rétroactivement qu'à construire correctement dès le départ. Je fais aussi passer une courte checklist NFR à chaque revue de conception pour que ces compromis remontent tôt, pas lors du premier audit de sécurité après le lancement.

Je traite d'abord cela comme une question de coût total de possession, la préférence technique venant en second. Construire sur mesure se justifie quand la capacité est proche de ce qui différencie réellement l'entreprise, et qu'une solution standard forcerait un compromis que les clients remarqueraient. Acheter a du sens pour une capacité commodity où le marché propose déjà des options matures et bien supportées: construire en interne revient souvent à réinventer un problème déjà résolu, en moins bien qu'un fournisseur qui ne fait que ça. Intégrer ce que l'organisation possède déjà est généralement le bon premier réflexe quand les licences ou l'infrastructure existantes couvrent l'essentiel du besoin et qu'une nouvelle plateforme ne se justifie pas face à l'écart marginal de capacité. J'utilise un modèle de notation pondérée sur le coût, le délai de valeur, le risque de dépendance fournisseur et la charge de maintenance, et j'intègre toujours le coût humain de faire tourner ce qu'on choisit, car une plateforme bon marché qui nécessite une équipe spécialisée n'est pas vraiment bon marché. Je présente les compromis avec des chiffres à l'appui plutôt qu'une simple recommandation, car la décision finale revient souvent à un responsable budgétaire, pas à moi.

Je garde deux versions de chaque artefact d'architecture: une vue technique détaillée pour les ingénieurs, généralement un diagramme de type C4 jusqu'au niveau container ou composant, et une vue narrative simplifiée pour les parties prenantes business, montrant les flux de données et les frontières du système sans détail d'implémentation. Face à un public exécutif, je commence par le résultat business et le risque géré, et je n'amène un diagramme que si quelqu'un demande comment, jamais en ouverture. J'ai appris à repérer le jargon qui me semble précis mais qui ne veut rien dire en dehors de l'engineering, donc avant une présentation importante je teste l'explication sur un collègue d'une autre fonction. Je tiens aussi des architecture decision records pour chaque choix significatif, rédigés en langage simple avec le contexte, les options considérées et le raisonnement, pour que six mois plus tard personne n'ait à reconstituer une décision à partir d'un fil Slack. Quand je suis en désaccord avec la direction préférée d'une partie prenante, je pose les compromis dans un tableau comparatif plutôt que d'argumenter, ce qui garde la conversation centrée sur la décision plutôt que sur qui a raison.

Je concevais la couche d'intégration pour un client retail, reliant une nouvelle plateforme de gestion des commandes à son système d'entrepôt existant. À mi-parcours de l'implémentation, nous avons découvert que l'API du système d'entrepôt avait une limite de débit non documentée, rendant notre pattern d'intégration synchrone prévu inutilisable pendant les pics de commandes, quelque chose qui n'apparaissait ni dans la documentation du fournisseur ni dans nos appels de discovery technique initiaux. Plutôt que d'essayer de négocier une augmentation de cette limite que le fournisseur ne pouvait pas garantir, j'ai redessiné l'intégration selon un pattern événementiel avec une file de messages, tamponnant les commandes pendant les pics et les traitant de façon asynchrone avec le système d'entrepôt, avec un callback de statut pour tenir la plateforme de commandes à jour. Cela a ajouté environ deux semaines au calendrier, que j'ai communiquées immédiatement avec l'architecture révisée et le raisonnement, plutôt que d'essayer d'absorber le retard en silence. Le client a accepté le délai une fois qu'il a compris que l'alternative était un système peu fiable pendant ses périodes de plus fort volume. La leçon que j'en tire: tester explicitement les limites de débit et les hypothèses de débit pendant le discovery, plutôt que de faire confiance à la documentation fournisseur telle quelle.

Un directeur commercial avait déjà annoncé à un client que notre plateforme pouvait supporter une synchronisation bidirectionnelle en temps réel avec leur ERP dans une fenêtre d'implémentation de six semaines, sur la base d'une conversation à laquelle je n'avais pas participé. L'ERP du client était un système on-premise fortement personnalisé sans API moderne, et une synchronisation bidirectionnelle en temps réel aurait nécessité soit un connecteur sur mesure avec un risque de maintenance continu important, soit une couche middleware qui n'avait aucune chance réaliste d'être construite et testée en six semaines. J'ai préparé une courte note technique pour le directeur commercial montrant les options d'intégration réelles, le calendrier réaliste de chacune, et la charge de maintenance de l'option la plus rapide, puis j'ai proposé une alternative phasée: synchronisation par lots dans la fenêtre de six semaines comme première livraison, avec le temps réel comme deuxième phase définie une fois le connecteur validé en production. J'ai présenté cela comme une façon de protéger la relation client plutôt que de bloquer la vente, car une intégration temps réel sur-promise qui casserait en production aurait fait bien plus de dégâts qu'un engagement phasé réaliste. Le directeur commercial a présenté la proposition phasée au client, qui l'a acceptée sans objection.

J'ai conçu une couche API gateway destinée à permettre à trois unités business de partager un ensemble commun de services backend plutôt que de maintenir chacune ses propres intégrations en doublon. Techniquement, elle fonctionnait exactement comme prévu, mais dix-huit mois plus tard, l'adoption était faible: deux des trois unités business avaient construit leurs propres intégrations point à point malgré tout, parce que le processus de changement de la gateway partagée passait par un comité de revue qui ajoutait, en moyenne, trois semaines de plus que ce que les équipes étaient prêtes à attendre. L'architecture en elle-même était solide, mais je n'avais pas conçu la gouvernance autour, et le chemin d'approbation lent a repoussé les équipes directement vers le pattern fragmenté que j'essayais d'éliminer. J'ai appris qu'une plateforme partagée vaut ce que vaut le modèle opérationnel qui l'entoure: qui peut demander un changement, à quelle vitesse, et qui possède le backlog. Sur les projets suivants, je conçois désormais la gouvernance et le SLA de toute plateforme partagée en même temps que l'architecture technique, et je traite un processus de changement lent comme un défaut de conception aussi sérieux qu'un problème de scalabilité, car il produit le même résultat: des équipes qui contournent le système qu'on a construit.

Je commence par profiler le système legacy: quelles interfaces il expose réellement, s'il a une API utilisable ou seulement un accès au niveau base de données ou fichiers, et son débit et sa disponibilité réels sous charge. S'il n'expose qu'une base de données, j'évite de me connecter directement aux tables de production depuis le côté cloud et je construis plutôt une couche anti-corruption, généralement un petit service qui possède la traduction entre le modèle de données legacy et le schéma attendu par la plateforme SaaS, pour qu'un changement d'un côté ne se propage pas directement dans l'autre. Pour le pattern de connectivité, je privilégie par défaut une couche iPaaS comme MuleSoft, Boomi ou Azure Integration Services plutôt que du code point à point sur mesure, car cela donne une surveillance centralisée, une logique de retry et une gestion d'erreurs prêtes à l'emploi, et c'est bien plus facile à maintenir pour l'équipe interne du client après la passation. Je privilégie une intégration asynchrone et événementielle partout où le processus business tolère une cohérence éventuelle, en utilisant une file de messages pour découpler les systèmes et absorber une panne d'un côté sans perdre de données. Et j'inclus toujours un job de réconciliation qui compare les nombres d'enregistrements et les champs clés entre les deux systèmes selon un calendrier, car les bugs d'intégration qui perdent ou dupliquent des enregistrements sont la classe de panne la plus difficile à détecter depuis les seuls logs applicatifs.

Je passe en revue une checklist standard couvrant la performance, la disponibilité, la sécurité, la scalabilité, la maintenabilité et la conformité, et pour chacune j'insiste sur un objectif mesurable plutôt qu'une formulation qualitative. Pour la performance, cela veut dire un temps de réponse précis à un percentile précis sous une charge concurrente précise, pas une promesse que ce 'devrait être rapide'. Pour la disponibilité, un objectif d'uptime explicite lié au coût business d'une indisponibilité, qui détermine ensuite si l'architecture a besoin d'une redondance active-active ou d'une conception mono-région plus simple avec un temps de récupération documenté. Je documente tout cela dans une matrice NFR avec la source de chaque exigence, pour qu'un objectif issu d'une obligation réglementaire soit clairement distingué d'une simple préférence interne, car les deux reçoivent un traitement très différent quand les compromis surviennent plus tard. Je signale aussi lesquelles sont des contraintes fermes et lesquelles sont des objectifs avec de la marge négociable, car traiter chaque exigence comme également figée est ce qui cause une sur-ingénierie inutile. Je révise la matrice à chaque jalon majeur, car les exigences fixées au début d'un projet sur des hypothèses précoces d'échelle ou d'usage doivent souvent être révisées une fois que de vraies données d'usage existent.

Je mène l'évaluation fournisseur comme un processus structuré plutôt qu'un exercice de préférence, en commençant par une matrice de notation pondérée couvrant l'adéquation fonctionnelle, l'effort d'intégration, le coût total sur un horizon de trois ans incluant l'implémentation et le support, la stabilité du fournisseur, et le coût de sortie si on doit migrer plus tard. Je demande toujours une preuve de concept sur nos exigences d'intégration réelles plutôt que de m'appuyer sur une démo fournisseur, car les démos sont construites pour cacher exactement les points de friction qui nous concernent. Je vérifie moi-même la documentation API et les limites de débit du fournisseur plutôt que de prendre la parole d'un ingénieur commercial pour argent comptant, car c'est là que je me suis déjà fait avoir sur des estimations de calendrier. Pour tout fournisseur détenant des données sensibles, je vérifie ses certifications de sécurité et ses options de résidence des données par rapport à nos exigences de conformité avant même de discuter des conditions commerciales, car un fournisseur qui échoue sur la conformité est disqualifié quel que soit le prix. Et je pondère fortement le coût de sortie: une plateforme bon marché à adopter mais coûteuse à quitter, à cause de formats de données propriétaires ou d'un manque d'outils d'export, porte un coût caché à long terme qui apparaît rarement dans le business case initial mais qui a coûté cher à chaque client avec qui j'ai travaillé et qui l'a ignoré.