C’est la question qui a été posée lors de la dernière commission R&D de Tech’In France animée par Daniel Cohen-Zardi, Président de SoftFluent. Tech’In France a été créée en octobre 2005 (nommée à l’origine l’Association Française des Editeurs de Logiciels et Solutions Internet) pour pallier le déficit de représentation de la filière numérique (Logiciel). Daniel Cohen-Zardi est président de cette commission depuis 2008 avec pour principal objectif de partager les expériences terrain sur les sujets d’édition de logiciels.

Frédéric Bouvard, Nicolas Robic, Geoffrey Janvier et Sylvain Cailliau sont donc intervenus pour essayer d’apporter une réponse à cette question.

Frédéric Bouvard est aujourd’hui CTO chez Finance Active

Dans le cas de l’application concernée,  le problème a été posé dans ces termes

• Aller vite et refactorer
• Prendre plus de temps pour poser une architecture scalable

Et poser le pour et le contre en tenant compte

• Des impacts du refactoring
• Du time to market

Au final, il a été décidé de poser immédiatement une architecture capable de tenir les forts volumes dans la mesure où le délai de 2 sprints était tout-à-fait acceptable.

Selon lui,

Ce qui est en production reste longtemps en production donc les choix doivent être structurants

En d’autres termes, le back end a vocation à durer alors que le front end doit pouvoir évoluer pour se différencier. D’ailleurs, un exemple qui illustre ce constat : le back end des portails bancaires est en cobol depuis 20 ans et ça fonctionne

Evidemment, l’ensemble doit se faire avec une vision globale, des choix techniques pertinents, de l’agilité avec le partage de la vision dans les équipes.

Nicolas Robic, actuellement Directeur de Naxos, la Digital Factory & DSIN de Century 21 France

Le rôle principal de cette filiale est d’apporter les meilleures solutions digitales, de collecter des données et de les faire fructifier pour apporter de la valeur. Nicolas nous a parlé de la solution CenturyNet qui a 20 ans d’existence avec 2 générations de produits et 4 vies.

Quand la solution est apparue sur le marché c’était évidemment pour durer, elle est d’ailleurs devenue produit de référence dans la mesure où il n’y avait pas de concurrence.

Et puis il a fallu faire face à l’actualité et à la réalité terrain : nouveau dirigeant, ouverture à la commercialisation, marque blanche, conception bouleversée, fusion, rachat, l’entreprise qui prend d’autres virages, le contexte et les technos qui évoluent, une dette technique…

Et faire la part des choses entre l’idéal et le pragmatisme et surtout ne pas s’obstiner !

Avec le recul, la stratégie que Nicolas a envie d’adopter aujourd’hui est la suivante :

• Un back-end solide évolutif le plus possible qui va passer l’échelle du temps avec le code métier au bon endroit
• Des modules (sous-produits) avec des durées de vie plus courtes pour tenir compte de l’obsolescence programmée

Selon lui

Il faut donc construire des systèmes ‘Darwiniens’ pour s’adapter aux tempêtes

Geoffrey Janvier, VP & Product Engineer chez Talentsoft

Pour lui,

Le choix de l’architecture dépend du niveau de maturité des entreprises car les contraintes ne sont pas mêmes : budget, expertise, compétence, maintenance, nombre d’utilisateurs, stabilité de la roadmap… Plus l’entreprise est importante, plus ses choix d’aujourd’hui vont impacter demain

Et aujourd’hui, il faut aussi tenir compte de l’évolution des contraintes extérieures

• Accessibilité
• GDPR

Notamment et ce n’est que le début !

Enfin, il faut tenir compte de la maturité du produit

• Co-innovation : POC (Proof of concept)
• Co-construction : MVP (Minimum Viable Product) qui va en production
• Co-amélioration : Legacy, interface à retravailler

En conclusion, prendre la bonne décision à un instant T

• Pas d’over-engineering
• Petit et granulaire : plus on découpe en composants, plus on pourra réagir vite
• Capable d’évoluer avec le temps

Sans contraindre ‘à priori’ les équipes dans le management

• D’abord une page blanche
• Puis un état des lieux
• Et enfin, les limites de coûts et de délais

Et enfin Sylvain Cailliau, Directeur Technique et évangéliste Marché chez Cast Software

Selon lui pour définir une architecture, il faut la séparer en typologie.

Fonctionnelle :

• Découpage vertical permettant d’isoler des silos ou blocs fonctionnels,
• Peu de dépendances vis-à-vis de l’infrastructure
• Parcours et expérience utilisateur

Technique :

• Découpage horizontal permettant d’isoler les couches techniques,
• Fort impact sur la capacité à prendre en compte de nouvelles technos critiques pour les nouvelles approches marchés
• Dépendances avec l’infrastructure

Sécurité :

• Intégration au croisement des couches techniques et des blocs fonctionnels et des blocs de validation de la sécurité
• Forte dépendance avec l’infrastructure
• Granularité des problèmes à gérer

Il faut aussi tenir compte des 3 niveaux du système d’information tels que définis par les analystes

• SI de Gestion : principalement des ERP/API ‘interne’/Stateless/architecture pour durer
• SI de Différenciation : applications Legacy/API ‘externe’/Microservices/architecture pour durer
• SI d’Innovation : nouveaux médias, UX, intégration/innovation rapide/disruption dans les modèles/ architecture pour innover

Evidemment, dans la réalité les frontières sont floues, les 3 niveaux d’architecture ont parfois tendance à s’imbriquer avec du code métier qui s’invite dans le code des frameworks. Il faut mettre en place un processus de contrôle continu d’architecture même si c’est compliqué.

En synthèse, il y a beaucoup d’éléments de réponse et pas forcément une solution unique.

Comme le souligne Daniel Cohen-Zardi,

Il faut tenir compte du fait qu’une ligne de code qui part en production y reste souvent pour longtemps, tout en découpant correctement pour permettre des changements qui se feront souvent par morceaux et selon des motivations et un calendrier qu’on ne connait pas encore

Se poser la question de la durée de vie de ce que l’on fait est aussi primordial, en gardant en tête que les interfaces utilisateurs évoluent plus vite que les fondamentaux des back-end.