FDE vs architecte solutions : du schéma à la production
Un architecte solutions répond à la question de savoir comment le système devrait être construit chez ce client : quels composants, quelles frontières, quels flux de données, quels arbitrages entre coût, sécurité et délai. Son livrable est une décision documentée, et son travail se termine quand cette décision est acceptée. Un forward deployed engineer répond à une question différente, qui ne se pose qu’après : ce que devient ce schéma quand des gens réels s’en servent avec des données réelles. Son livrable est un système en fonctionnement, et son travail se termine quand quelqu’un s’en sert sans lui. Les deux métiers sont complémentaires et se disputent rarement sur le fond, parce qu’ils ne sont presque jamais dans la même pièce au même moment. Le conflit apparaît ailleurs : dans l’écart entre le schéma validé en comité et ce que le troisième mois de déploiement révèle, et dans la question de savoir qui paie le coût de cet écart.
| Forward deployed engineer | Solutions architect | |
|---|---|---|
| En une phrase | Un ingénieur employé par l’éditeur, qui travaille dans l’organisation du client pour que le produit règle le vrai problème de ce client. | Celui qui conçoit le système cible : comment les pièces s’assemblent, quelles sont les contraintes, et ce que le client doit construire. |
| Jugé sur | Le fait que le travail du client ait changé, et que le changement ait survécu à son départ. | Le fait que la conception survive à la réalité du client et à sa revue de sécurité. |
| Travaille dans | Les systèmes, les données et les réunions du client, souvent dans ses locaux. | Des schémas d’architecture, des implémentations de référence, des normes et des comités. |
| Mène le plus souvent à | Diriger une équipe de déploiement, ou le management produit avec une crédibilité terrain rare. | Architecte principal, ou un rôle de directeur technique terrain. |
| Temps passé chez le client La part de la semaine passée avec ceux qui emploieront la chose. | Élevé | Moyen |
| Profondeur technique Jusqu’où va l’ingénierie attendue du poste. | Élevé | Élevé |
| Profondeur métier À quel point le poste doit comprendre le métier du client lui-même. | Élevé | Moyen |
| Écriture de code La part du travail qui consiste réellement à écrire et intégrer du logiciel. | Élevé | Faible |
| Responsable du résultat Si le poste est jugé sur la livraison, ou sur ce que la livraison a changé. | Élevé | Faible |
Ces niveaux décrivent le centre de gravité d’un poste, pas une règle. Les intitulés ne sont normalisés nulle part : une offre donnée peut se situer loin de sa colonne. Lisez ce qu’elle dit que la personne va construire plutôt que son titre.
Deux horizons de temps
L’architecte raisonne à trois ans. Ses décisions portent sur des choses coûteuses à changer : le modèle de données, les frontières entre systèmes, le mode d’authentification. Il a raison de raisonner ainsi, parce que ce sont précisément les choix qu’une organisation ne rouvrira pas avant longtemps.
Le forward deployed engineer raisonne à trois semaines. Sa question est de savoir ce qui peut être mis entre les mains de quelqu’un avant la prochaine revue de projet, parce que la confiance d’un client se construit par des livraisons visibles et se perd par des mois de silence.
Aucun des deux horizons n’est le bon. Un déploiement conduit uniquement à trois semaines produit un empilement que personne ne pourra maintenir ; un déploiement conduit uniquement à trois ans n’arrive jamais au contact et meurt d’un changement de priorité chez le client. Les projets qui réussissent tiennent les deux, et cela suppose que les deux rôles se parlent bien après la phase de conception, ce qui est rarement organisé.
Ce que le schéma ne prévoit jamais
Les documents d’architecture se trompent rarement sur la technique. Ils se trompent systématiquement sur trois autres points, et un ingénieur de déploiement expérimenté les cherche dès la première lecture.
L’état réel des données. Le schéma suppose un champ renseigné ; il l’est à soixante pour cent, et les quarante pour cent manquants suivent une logique que seule une équipe opérationnelle connaît. Cette découverte arrive toujours, et elle arrive toujours plus tard qu’elle ne le devrait.
Les personnes. Le schéma indique qu’un processus est automatisé, sans dire que trois personnes en vivent aujourd’hui et qu’aucune n’a été prévenue. Cela n’invalide pas la conception, mais cela change entièrement le calendrier.
Les délais d’autorisation. Un accès en lecture à une base de production se demande en une ligne dans un document et s’obtient en cinq semaines dans une banque. Un plan qui ne compte pas ces délais n’est pas un plan optimiste, c’est un plan faux.
Qui paie l’écart
Dans la plupart des organisations, l’architecte n’est plus présent quand l’écart se manifeste, et c’est l’équipe de déploiement qui l’absorbe. Ce n’est pas une injustice théorique : cela produit deux comportements observables et coûteux.
Le premier est la dérive silencieuse. L’équipe de déploiement s’écarte du schéma pour tenir les délais, sans le documenter, parce que rouvrir la conception demanderait un comité. Six mois plus tard, le système en production et le système documenté n’ont plus grand-chose en commun, et le client hérite des deux.
Le second est l’inverse, plus rare et plus grave : l’équipe respecte un schéma qu’elle sait inadapté, parce qu’il a été validé plus haut. Le projet livre alors quelque chose de conforme et d’inutilisable, ce qui est la seule catégorie d’échec dont personne ne parle en réunion de clôture.
Le remède connu est simple et peu appliqué : garder l’architecte disponible, en temps limité mais réel, pendant les deux premiers mois de mise en œuvre, avec le mandat explicite de modifier sa conception. Cela coûte quelques jours et évite des trimestres.
Passer du déploiement à l’architecture
C’est une trajectoire fréquente, et elle intervient souvent au moment où les déplacements cessent d’être tenables. Le passage se fait bien, à une condition.
L’atout apporté est considérable : avoir vu vingt organisations réelles donne une intuition que l’architecture de formation ne produit pas. Vous savez quelles décisions survivent au contact et lesquelles sont défaites dès le premier trimestre, parce que vous les avez défaites vous-même.
Le risque est de continuer à concevoir pour le cas que vous avez vécu. Vingt clients, c’est beaucoup d’expérience et un échantillon étroit, et un architecte qui généralise à partir de son dernier déploiement difficile produit des schémas surprotégés contre un problème qui ne se reproduira pas.
Les meilleurs, dans ce passage, gardent une habitude du métier précédent : ils vont voir. Un architecte qui passe deux jours en salle avec les utilisateurs avant de figer un modèle de données produit un document d’une autre qualité, et il n’a besoin de personne pour lui expliquer pourquoi.
