Tout langage, tout cloud : pourquoi nous restons agnostiques

L'une des premières questions que l'on nous pose porte sur la technologie que nous utilisons. C'est une question légitime, et notre réponse peut sembler évasive au premier abord : nous utilisons celle qui convient. Nous travaillons dans les langages et les frameworks sur lesquels une organisation s'appuie déjà, nous déployons dans le cloud qu'elle a choisi ou sur un hébergement que nous gérons nous-mêmes, et nous continuons d'exploiter ce que nous construisons.

Ce n'est pas un slogan. C'est une position de conception, et elle a des conséquences sur la façon dont les applications sont façonnées, gouvernées et maintenues. Cet article en explique le raisonnement.

Agnostique ne veut pas dire indifférent

Être agnostique ne veut pas dire ne pas avoir d'opinion. Nos architectes ont des convictions fortes sur ce qui rend un système maintenable, sûr et agréable à faire évoluer. Ce que nous évitons, c'est de partir d'une pile technologique favorite et d'y faire entrer l'organisation.

Chaque choix technologique échange un ensemble de contraintes contre un autre. Le bon arbitrage dépend de l'organisation, pas du fournisseur. Un choix excellent pour un client peut devenir un handicap pour le suivant, parce que les personnes, les systèmes et les obligations autour de l'application sont différents.

Les contraintes qui décident

Quand nous façonnons une application, la technologie découle d'une poignée de questions propres à l'organisation.

• Qui vivra avec ? Si une équipe interne doit maintenir une partie du système, les langages qu'elle connaît comptent plus que ceux que nous préférons.
• Avec quoi doit-elle communiquer ? Une application est rarement isolée. L'ERP, le CRM, le fournisseur d'identité et les outils de reporting déjà en place déterminent ce qui s'intègre proprement.
• Où les données peuvent-elles résider ? Le droit de la vie privée, les contrats et les politiques internes peuvent décider quelles régions et quels fournisseurs sont acceptables, avant même qu'une préférence technique n'entre dans la conversation.
• Comment sera-t-elle exploitée ? La supervision, les sauvegardes, les mises à jour et la réponse aux incidents doivent correspondre aux personnes et aux processus qui les porteront, jour et nuit.
• Comment en sortiriez-vous ? Chaque système devrait avoir une porte de sortie crédible : vers un autre fournisseur, vers une autre équipe, ou de retour en interne.

Ces questions sont posées tôt, et les réponses sont consignées avec le reste de la conception. Elles ne sont pas laissées pour la fin d'un projet, quand les changer coûte cher.

L'endroit où elle s'exécute est une décision de conception

L'hébergement est souvent traité comme un détail opérationnel, réglé une fois l'application construite. Nous le traitons comme une partie de la conception. Une application peut s'exécuter dans le cloud de l'organisation, dans son propre centre de données, ou sur une infrastructure gérée par Croo. Chaque option comporte des responsabilités différentes en matière de sécurité, de disponibilité et de coûts, et le choix appartient à l'organisation.

Pour que ce choix reste réel, l'environnement cible est décrit dans la configuration plutôt que tissé dans le code. Voici à quoi ressemble un enregistrement simplifié, à titre d'illustration :

# L'endroit où tourne le portail d'achats est consigné avec sa conception.
application: purchasing-portal
packaging: container
environments:
  - name: acceptance
    hosting: client-cloud
    data-residency: canada
  - name: production
    hosting: client-cloud
    data-residency: canada
fallback:
  hosting: croo-managed
  reason: reste disponible si l'équipe plateforme change de cap

La valeur n'est pas dans le format du fichier. Elle est dans la discipline : l'application ne présume pas de l'endroit où elle vit, si bien que la déplacer devient un projet délibéré plutôt qu'une réécriture.

Garder la porte de sortie ouverte

La dépendance à un fournisseur vient rarement d'une seule décision. Elle s'accumule au fil de petites commodités : un service propriétaire ici, un script non documenté là. Rester agnostique, c'est résister à cette accumulation pour le compte du client.

En pratique, cela passe par quelques habitudes.

• Un empaquetage portable. Les applications sont empaquetées pour s'exécuter de la même façon dans tout environnement qui prend en charge les conteneurs standard, afin que l'organisation ne soit pas liée à l'environnement d'exécution d'un seul fournisseur.
• Une infrastructure décrite sous forme de code. Les environnements sont créés à partir de définitions revues, et non assemblés à la main, pour pouvoir être recréés ailleurs.
• Des données ouvertes. L'organisation peut exporter ses données dans des formats documentés, à tout moment, sans notre aide.
• Une documentation qui voyage. Les décisions, l'architecture et les procédures d'exploitation vivent dans la trace partagée, pour qu'une autre équipe puisse prendre le relais.

Rien de tout cela n'empêche d'utiliser le meilleur service qu'offre un fournisseur. Cela signifie savoir, et écrire, ce que ce choix coûterait si les circonstances changeaient.

Ce que l'agnosticisme exige de nous

Travailler avec de nombreux langages et clouds est plus difficile que de se spécialiser dans un seul. Cela exige de l'étendue dans l'équipe et de la discipline dans la façon de conserver le savoir.

Deux choses le rendent soutenable. La première est la mémoire partagée de la Factory : les modèles, les décisions et les leçons tirées d'une pile technologique sont consignés d'une façon que le travail suivant peut exploiter. La seconde est la production assistée par l'IA, qui réduit l'effort nécessaire pour travailler dans un framework moins familier ou lire une base de code inconnue. Le jugement sur l'architecture, la sécurité et les compromis appartient toujours à des profils seniors qui en répondent.

La gouvernance dès la conception

Choisir où s'exécute une application est aussi une décision de gouvernance. La résidence des données, le contrôle des accès, le chiffrement, les sauvegardes et le traitement des données personnelles se règlent dans la même conversation que la technologie, et sont consignés avec elle.

C'est pourquoi nous classons ce sujet sous la gouvernance dès la conception. Une organisation devrait pouvoir dire, à tout moment, où ses applications s'exécutent, qui peut y accéder, pourquoi ces choix ont été faits et comment elle pourrait les changer. Rester agnostique, c'est notre façon de laisser ces réponses entre les mains de l'organisation.

En bref

Nous ne vendons pas une pile technologique. Nous construisons des applications d'entreprise dans les langages et sur les clouds qui conviennent à l'organisation, ou nous les exploitons nous-mêmes quand c'est la meilleure réponse. Les contraintes décident, les choix sont consignés, et la porte de sortie reste ouverte.