Easy Tech #16 - l'architecture pourquoi faire ?

Un composant essentiel de tout produit

Salut salut,

J’espère que tout va bien pour toi ! Les vacances se rapprochent 😎 ou peut-être même que tu en profites déjà.

mon côté j’étais de mariage ce week-end, ça a été mouvementé mais on a surtout passé un super moment. J’ai dû ressortir mon uniforme de l’X pour l’occasion. Heureusement, ça n’a pas duré trop longtemps car il faisait chaud !

Aujourd’hui on va parler d’architecture, un sujet important et délicat ! Si tu préfères une version vidéo sur le sujet, je te conseille d’aller jeter un oeil à ce live que j’avais animé avec Pierre Criulanscy sur le sujet.

Trois petites histoires pour démarrer

Un POC data qui a du mal à passer à l’échelle

Contexte

Je bossais pour un ministère (encore un) et on les aidait au niveau RH ! On voulait réduire le taux de démission des employés les premières années. En gros, ils avaient l’intuition qu’ils ne “qualifiaient” pas suffisamment les candidats qui venaient chez eux. Donc assez logiquement, les employés s’en allaient très vite pendant l’équivalent de la “période d’essai” c’est à dire après quelques mois, voire 1 an, 1 an et demi.

C’est un use-case assez classique de Statistiques / Machine Learning / IA (les liens vers les deux newsletters Easy Tech #11 et Easy Tech #12 sur le sujet si tu les as ratés). On va regarder différentes caractéristiques des candidats puis on va regarder dans quelle mesure ces caractéristiques influencent ou pas la probabilité de démission.

Ça marche bien en théorie, mais en pratique…

Anecdote

💡 Première anecdote : sortir la donnée

On a eu de grosses difficultés à récupérer la donnée pour pouvoir commencer à faire nos calculs. Le fait que ça soit un ministère a évidemment pas arrangé les choses ! Pour plein de bonnes raisons (confidentialité, souveraineté), les administrations sont très frileuses et conservatrices vis à vis de leurs données.

Pas possible de sortir de la data comme ça.

Là, en plus, on parlait de donnée RH ! Potentiellement, c’est vite sensible car ça peut contenir des informations nominatives (nom, prénom, adresse etc).

Pour autant, le use case était pertinent, et il fallait le tenter. Certes, il faut être vigilant avec la donnée RH, mais tu dois pouvoir te débrouiller pour extraire des bases “cleans” sans se mettre en difficulté d’un point de vue éthique ou légal (RGPD)… Et c’est ce qu’on a fait.

On a bossé avec le client pour identifier les différentes caractéristiques à extraire : ❌ pas tout ce qui est nom, prénom etc… ✅ mais diplôme, premier poste, expérience pro préalable… Ça nous a permis de construire une belle base de données à exploiter par la suite.

⚠️ Problème : on a fait attention aux infos nominatives, mais c’est pas pour autant que c’est automatique de sortir la base.

Vu que c’était de la donnée RH, le client nous a fait comprendre que la seule solution, c’était tout simplement qu’il nous passe ça via une clé USB… sous le manteau en gros 😅. Pas top.

Ça illustre bien l’ambivalence des enjeux d’architecture et de gouvernance IT :

→ Tu as besoin de mettre en place des contraintes liées à ce que tu fais avec son système d’informations et aux données que tu y stockes. C’est le rôle de tes architectes notamment de définir tout ça. Et ces contraintes doivent être protectrices.

→ En revanche, quand ça devient trop contraignant, la réaction est immédiate et toujours la même : du contournement. C’est aussi ce qu’on appelle le Shadow IT. On n’était pas très fiers de passer par une clé USB. Mais sinon, c’était impossible de faire avancer ce cas d’usage qui apportait beaucoup de valeur.

💡 Deuxième anecdote : un passage à l’échelle impossible

C’est par la suite qu’on a compris aussi l’importance de l’architecture pour notre cas d’usage.

À vrai dire, au début, il n’y avait pas d’architecture ou de système en tant que tel. On avait une base de données. Je faisais tourner du code dessus pour modifier la base de données, identifier des trucs et générer des graphes.

À court terme, ça suffisait. En fait, à ce stade, on voulait juste confirmer une intuition. On voulait savoir s’il y avait bien des caractéristiques des candidats qui permettaient d’anticiper une éventuelle démission.

🤯 Et c’est ce qu’on a vu ! On a constaté qu’il y avait une corrélation entre certaines caractéristiques et la probabilité de démission rapide.

À partir de là, tu exploites en général ce genre d’insights de deux manières :

→ 1️⃣ tu utilises les découvertes pour les communiquer aux recruteurs / RH, afin de les prévenir que certains paramètres sont des bons prédicteurs et inversement que d’autres n’ont pas d’impact. ⚠️ Il faut bien préciser que ce sont des calculs basés sur une population, pas forcément représentative etc… Mais c’est toujours intéressant de communiquer cette info.

→ 2️⃣ en étant plus ambitieux, l’idée serait “d’industrialiser l’approche”. Plutôt que d’avoir mon fichier excel et mes scripts Python sur mon ordi. Pourquoi ne pas directement avoir une application qui te donne un “scoring” pour chaque candidat qui arrive en fonction de ses caractéristiques ? On passe sur du Machine Learning / IA : on arrive à effectuer des prédictions sur de nouvelles données.

L’idée était hyper tentante mais on n’a jamais réussi à faire tourner ça en production.

Les deux obstacles principaux :

→ 1️⃣ le processus qu’on avait créé pour extraire la donnée puis réaliser les calculs dessus était pas du tout reproductible. 😂 Comment tu veux industrialiser une procédure qui passe par un échange de clé USB à un moment ? 🤔 Mais encore une fois, on était condamné dès le départ. Pas possible de faire autrement. Dans un monde idéal, il y aurait eu une API sur la base RH pour pouvoir récupérer la donnée facilement, de manière clean. Évidemment, ça n’était pas le cas.

→ 2️⃣ ça posait beaucoup de questions autour de l’hébergement de l’application : sur le Cloud ? Sur les serveurs du ministère ? Et évidemment, ça penchait plutôt pour la deuxième solution. Mais donc ça voulait probablement dire que tout ce qu’on avait fait était à refaire ! Pas sûr que tu puisses installer Python et faire tourner tes scripts facilement sur ces environnements.

L’enseignement principal de cette histoire c’est que dès que tu veux commencer à construire des applications (à “faire des trucs sérieux” au niveau tech). Ne fais pas les choses à la main, de manière un peu dégueu en bricolant à droite à gauche. Ça ne passera pas à l’échelle. Et même si l’idée est bonne ; ça sera très dur à implémenter.

Un monolithe difficile à bouger et des microservices spaghetti…

Contexte

Chez un de mes anciens clients, j’intervenais en tant que Product Manager sur une application importante. Par ailleurs, je les aidais également sur la mise en place de l’agile, du Product Management et du DevOps. Ils avaient de gros enjeux tech car leur architecture était “à deux vitesses”.

→ Premièrement, on avait un vieux système. Très ancien. Qui tournait depuis de longues années. On parle souvent de “Legacy” pour désigner ces vieux systèmes. Au niveau de l’architecture il y avait plein d’imbrications. Et personne ne savait très bien comment le manipuler. Il y avait un côté “monolithique”, compact, d’un seul tenant.

→ Deuxièmement, on avait une application très récente, plus moderne ! On avait eu un besoin urgent de construire un nouveau produit. Plutôt que de capitaliser sur le “legacy” ce qui ne nous semblait pas pertinent. On a préféré recréer une application “de zéro”. On a pu mettre en place un type un peu à la mode d’architecture : une architecture microservices.

💡 Quelle différence entre monolithe et microservices ?

C’est une question complexe et je dédierai une édition de la Newsletter à ce sujet (n’hésitez pas à me le dire par retour de mails si ça vous intéresse).

Pour résumer simplement :

Monolithe = application compacte, elle bouge toute entière et on la déploie d’un coup. Difficile de faire évoluer / déployer une petite fonctionnalité de manière indépendante.

Microservice = application très découplée, avec plusieurs modules qui répondent à un besoin utilisateur propre. On peut déployer / faire évoluer chaque petit module de manière indépendante.

(pour creuser je vous conseille cet article de Martin Fowler)

Anecdote

💡 Première anecdote : “on ne peut pas toucher au legacy”

Comme je l’expliquais, on avait ce gros système dit “legacy” qui était là depuis très longtemps. Le problème, c’est qu’il tournait en production. Donc ça répondait à des vrais besoins, de vrais utilisateurs. Du fait de ces enjeux, on était stressés à l’idée de le faire évoluer. Grosso modo, ça arrivait peut-être 1 ou 2 fois par an… mais pas plus 😅

Pourquoi on “touchait peu” au legacy ?

→ 1️⃣ On n’était pas sûrs de comment il allait réagir si on le faisait évoluer. Du fait de l’ancienneté des technologies et parce que les personnes qui avaient bossé dessus étaient parties depuis. Entre créer un gros problème qui impacte des utilisateurs OU juste laisser ce truc pourrir / vieillir mais sans impact direct… on avait choisi la deuxième option plus conservatrice.

→ 2️⃣ Au niveau des fonctionnalités, on n’avait peu d’évolutions à mettre en place. Quelques toutes petites mises à jour mais c’était très très light. On n’avait pas besoin d’avoir une équipe staffée à 100% pour s’occuper de cette application.

Pour autant, cette inertie entraînait des problèmes :

→ Premier problème : des technologies trop anciennes. À force de dire “on n’y touche pas parce qu’il n’y a pas de nouvelles fonctionnalités”, on ne touche plus aux technologies sous-jacentes qui ont aussi un impact sur l’expérience utilisateur. Par exemple, on avait des versions de Mysql qui étaient hyper anciennes, ce qui fait qu’on avait dû implémenter à la main des trucs qui étaient maintenant direct intégrées dans des versions Mysql ultérieures.

→ Second problème : une inertie contagieuse. Une application n’est jamais purement isolée. Elle va toujours servir pour d’autres applications, d’autres acteurs. Dans ce cas, son inertie est dommageable pour les autres. OK le legacy n’évoluait jamais. Mais les autres applications qui voulaient juste capitaliser sur une mini brique de ce legacy étaient ralenties par son rythme.

On avait en plus un effet “cercle vicieux” :

Moins on fait d’évolutions car le système est vieillissant

⇒

Plus les évolutions nécessaires se passent mal

⇒

Moins ça nous motive à en faire

⇒

Moins on fait d’évolutions etc…

💡 Deuxième anecdote : la douche froide des microservices

Comme je vous le disais, la deuxième application était architecturée avec des microservices ! C’est un type d’architecture qui est (était) très à la mode. Netflix avait notamment beaucoup mis en avant cette manière de faire et vanté les vertus que ça avait en termes de scalabilité.

La force des microservices en effet, c’est que comme il y a plein de petits modules bien découpés. Dès qu’un module est plus sollicité que les autres, on va créer des copies de ce petit module pour être sûr de bien répondre efficacement aux demandes des utilisateurs.

(Sur une application plus compacte et grosse comme un monolithe, c’est pas facile. Ne serait-ce parce que c’est moins anodin de créer des copies d’un très gros engin.)

Donc le client était passé par un prestataire qui lui avait créé de super microservices flambants neufs.

Le hic, dans tout ça… c’est qu’on n’était pas trop trop contents de l’application.

Pour trois raisons :

→ 1️⃣ d’abord le processus de décision avait été un peu trop “top-down”. Pour la faire simple, le prestataire avait très bien vendu au “décideur” / chef de lui faire une super application moderne. Les architectes et les opérationnels avaient pas suffisamment été impliqués dans l’affaire. La conséquence de ça, c’est que les archi et opérationnels, ne comprenaient pas trop quels étaient les avantages et bénéfices qu’on visait via ce type d’archi. C’était pas de la mauvaise foi à vrai dire. Mais quand (i) on t’impose un truc ; (ii) sans t’expliquer ce qu’il y a pour toi derrière… pas top top

⇒ Enseignement 1️⃣ : bien clarifier les objectifs et enjeux derrière un choix aussi structurant. C’est normal que le décideur décide au final (c’est son boulot 😂). Mais si les indicateurs clés de succès ne sont pas clairs, c’est mauvais signe.

→ 2️⃣ ensuite plusieurs choses étaient devenues plus complexes. On espérait plein de bénéfices et peu d’inconvénients. Au final, on voyait beaucoup de nouveaux inconvénients (et peu de bénéfices cf 1️⃣). De manière simplifiée, le processus de déploiement est plus morcellé quand on est sur une application microservices. Sur un monolithe, tu déploies tout d’un coup : boum. Sur une archi microservices, tu déploies chaque microservice un par un. Donc ça requiert d’être efficace et fort sur ces enjeux ! Tu multiplies par 3-4-5-10 (en fonction du nombre de microservices), le nombre de déploiements à faire.

⇒ Enseignement 2️⃣ : ne pas être trop optimiste et uniquement anticiper des avantages. Il faut être clair sur les inconvénients en amont ! Il n’y a jamais de truc magique dans la tech. Il faut savoir à quoi s’attendre.

→ 3️⃣ enfin on ne disposait pas des bonnes compétences pour piloter ça en interne. C’est d’ailleurs sûrement la cause des deux autres points. C’est un problème hyper récurrent et pas seulement côté tech. On a toujours envie d’acheter les produits tout récents. Sortis il y a quelques mois. Attention, si tu t’achètes des jets privés luxueux et incroyables… mais que tu ne sais pas les piloter ; peut-être que tu aurais mieux fait d’investir dans une voiture moins chère, et que tu sais gérer. Ça peut paraître anecdotique mais c’est un vrai sujet sur les ventes d’avions Rafale par la France. Derrière, il faut former les futurs pilotes pour que ça soit utile. Si on revient à mon client, ça introduisait une double frustration : (i) l’impression perpétuelle d’être arnaqué (puisqu’on ne comprend pas, on est suspicieux) ; (ii) la non-maîtrise en interne de l’application (le jour où le prestataire s’en va, on est livrés à nous-même).

⇒ Enseignement 3️⃣ : mieux vaut choisir un outil moins perfectionné, mais qu’on maîtrise, plutôt qu’un truc performant qu’on ne maîtrise pas. Quitte à transitionner du moins perfectionné vers le truc performant quand on est à l’aise.

L’architecture quand on est beaucoup

Contexte

À plusieurs reprises j’ai bossé dans des plus grandes structures; des grands groupes au sens large. Pas forcément côté secteur privé d’ailleurs, ça peut aussi être dans le secteur public. En général, l’architecture prend une tournure différente dans ces endroits. Souvent parce que les logiciels, les assets tech ne sont pas historiquement dans le coeur de métier de la structure.

Un des gros enjeux dans ces organisations, c’est de contrôler ce qu’il se passe au niveau informatique. Dès que la structure commence à avoir une taille significative, on a un risque important qu’il y ait plein de logiciels qui soient construits à droite à gauche, sans forcément appliquer des bonnes pratiques, sans qu’on puisse non plus en contrôler les coûts. On met souvent en place des “Comités d’architecture” pour superviser tout ça.

Anecdote

💡 Première anecdote : sans architecture, tout le monde fait n’importe quoi

On parlera des comités d’architecture dans la deuxième anecdote. Mais avant, je pense que c’est important d’être conscient de comment les choses se passent sans architecture. Clairement, c’est très compliqué car tout le monde fait un peu les choses “à sa sauce”.

→ Tu as envie de lancer un nouveau produit avec cette nouvelle techno ? OK GO vas y.

→ Tu penses qu’il faut mettre en place ce genre de base de données ? OK GO vas y.

→ Tu as envie d’acheter ce nouveau SaaS qui a l’air dingue. Tu as le budget ? OK GO vas y.

Bref c’est un peu caricatural. Mais dans un contexte de grande structure. Avec des acteurs responsabilisés en son sein, on a un risque important de dérive avec :

→ 1️⃣ des logiciels créés “redondants” : comme les services n’échangent pas nécessairement et comme aucune personne n’est chargée de la supervision transversale sans architecture, on va peut-être avoir plusieurs logiciels achetés ou créés pour répondre à un même besoin. Or, c’est dommage car en identifiant cela en amont, on aurait pu éventuellement mutualiser les coûts ou prendre une décision plus éclairée.

→ 2️⃣ des risques techniques importants : si tout le monde fait les choses dans son coin, on risque de ne pas mettre en place des bonnes pratiques, d’avoir des architectures pas top, d’avoir des failles de sécurité qui se baladent. Ce n’est pas pour dire qu’il faut tout contrôler de manière hyper hyper poussée. En revanche, il faut le bon niveau de contraintes et de contrôles pour assurer un niveau de qualité minimum. Sans rôle d’architecte ou comité d’architecture, difficile de garantir cela.

C’est ce qui justifie la mise en place de comités d’architecture et d’architectes. Grosso modo, leur responsabilité va être :

→ D’abord d’apporter une visibilité sur l’ensemble du portefeuille applicatif = l’ensemble des produits / logiciels développés au sein de la structure. L’état de ce portefeuille à un instant donné, puis de suivre ses évolutions dans le temps.

→ Ensuite proposer des bonnes pratiques et des standards qui facilitent la vie de tout le monde et améliorent la qualité globale du portefeuille. Par exemple, pour éviter des failles de sécurité qui se baladent ou pour avoir des logiciels plus éco-responsables.

💡 Deuxième anecdote : “tu veux tester cet outil ? OK tu dois passer devant 10 comités”

En revanche, évidemment, rajouter une étape dans un process, rajouter un comité de validation, c’est forcément être un peu moins agile ! On a vu les avantages que ça présentait dans l’anecdote numéro 1. Mais c’est forcément un choix qui implique également quelques inconvénients.

J’en identifie deux principaux :

→ 1️⃣ C’est plus dur de faire de l’innovation. En fait le comité d’architecture c’est quand même une étape pas si facile que ça à passer. Tu es souvent obligé d’avoir un passage devant pour récupérer du budget ou a minima avoir un projet qui puisse être durable. Forcément, ça t’incite moins à tenter plein de trucs ! Tu te dis “oui j’ai envie d’essayer ça, mais derrière je vais devoir passer en Comité d’architecture”. Donc tu préfères attendre d’être vraiment sûr que ça en vaille la peine. Dommage 😒 parce que ça t’incite un peu moins à le faire. Et ça vaut d’ailleurs (i) à la fois pour les logiciels développés en interne ; (ii) à la fois pour des licences SaaS que tu vas acheter.

→ 2️⃣ Ça pousse à faire des plans sur la comète. Comme le passage en comité d’archi est un moment important, tu veux bien le préparer et tu veux que ça se passe bien. Forcément, ça va t’inciter à essayer de “vendre du rêve”. Tu ne veux pas arriver et dire “on veut tester ça, ça a l’air pas mal”. Personne n’aura envie de te valider ça ou de te donner du budget pour ça. En outre, vu que tu veux avoir des marges de manoeuvre, tu vas potentiellement “vendre” un périmètre de projet significatif, histoire de récupérer du budget et d’être un peu tranquille. Le problème avec tout ça, c’est qu’une fois que tu as vendu un truc génial, tu vas avoir envie de le développer coûte que coûte (tu t’es engagé à faire ça). Ça t’aide pas à être agile. Tu vas plutôt “follow the plan” et pas “adapt to change” (cf le Manifeste Agile pour avoir la référence).

Du coup, on en pense quoi de ces comités d’architecture ? 🤔

Ça va beaucoup dépendre des contextes et des organisations.

Je pense déjà qu’il faut être conscient, et les deux anecdotes le montrent, qu’il n’y a pas de solution parfaite. Il faut une forme de contrôle et de centralisation, a minima. Ce qui implique, a minima également, d’accepter les inconvénients que ça implique.

Empiriquement, je remarque que limiter ces inconvénients passe souvent par trois principales choses :

→ 1️⃣ Avoir suffisamment de ressources côté archi pour faire un pilotage continu et non ponctuel des projets / produit. Comme ça, on sacralise moins ces passages en comité. Ce qui compte, c’est le contrôle continu.

→ 2️⃣ Sanctuariser des marges de manoeuvre pour laisser les équipes innover, sur des projets de petite ampleur mais avec un peu de budget. Par exemple, si tu veux essayer un SaaS qui coûte 300€ par an, c’est OK pas besoin de passer en comité.

→ 3️⃣ Ne pas avoir un comité “one shot”, mais privilégier des points de contact réguliers dans le temps et itératifs. C’est très proche du point 1️⃣, pour éviter le côté “sanctuarisé” où on va jouer la vie ou la mort du projet sur une seule réunion.

Pourquoi c’est important ?

1️⃣ Si tu n’es pas acteur de son archi, tu la subis

C’est ce qu’on a vu dans l’anecdote 2. Quand on ne pense pas à l’architecture… l’architecture nous le fait regretter.

C’est important de se rendre compte qu’il y a toujours un petit peu d’architecture. Quelque soit la simplicité de ton application. À ne pas négliger donc.

Par ailleurs, les actions d’architecture ont en général un retour investissement à long terme ou en tout cas pas direct et immédiat. Aussi dans le jeu de la priorisation, elles se font souvent passer devant pour des actions avec un bénéfice immédiat. Ça ne veut pas dire qu’il ne faut pas mettre en place d’actions à RoI direct, plus qu’il faut avoir conscience de cet arbitrage court terme / long terme.

2️⃣ Un bon logiciel, c’est une bonne architecture

De manière un peu simplifiée, un bon logiciel c’est un logiciel de qualité à deux niveaux.

→ Qualité au niveau de la valeur apportée à l’utilisateur. Or pour délivrer de la valeur, il faut itérer avec cet utilisateur, ajuster et changer des éléments. Pour réussir à faire ça vite et bien, il faut une application facile à faire évoluer. Et c’est exactement un des avantages d’une bonne architecture.

→ Qualité au niveau technique : pour être bien fait, un produit doit être performant. Bien fait techniquement. Avec les bonnes technologies et les bons choix notamment architecturaux. Donc par définition, un bon logiciel = un logiciel de qualité au niveau technique = une bonne architecture.

3️⃣ C’est plus facile à gérer

L’architecture vise à découpler les composants des logiciels ; à séparer les différentes parties les unes des autres. Ça permet de cloisonner et c’est très pratique !

C’est comme quand tu construis une maison. Tu n’as pas envie que la salle de bains soit dans la chambre. Ou que la cuisine soit dans les toilettes. Chaque pièce a une fonction précise. Ces fonctions ne sont pas mélangées sinon c’est désagréable.

Côté logiciel, c’est la même chose et ça entraîne notamment 2 conséquences.

→ 1️⃣ Les bugs sont mieux contenus et plus faciles à identifier. Si j’ai une fuite d’eau quelque part dans mon appartement, et que les pièces sont bien cloisonnées, je sais que la fuite d’eau ne peut pas provenir a priori de la chambre à coucher. Ça fait moins d’endroits dans lesquels chercher.

→ 2️⃣ Les choses sont mieux organisés et rangés donc c’est plus facile de monter en compétences pour les personnes qui viennent bosser sur le produit. Dans l’anecdote du legacy typiquement, c’était un gros problème car personne ne comprenait comment fonctionnait ce gros monolithe. S’il avait été découpé en des petits morceaux indépendants, ça aurait été plus facile à prendre en main.

Quelques conseils concrets pour une meilleure archi

Conseil 1️⃣ prendre conscience que c’est important

C’est la première étape avant de pouvoir changer les choses. Comment on fait pour prendre conscience ? Être factuel et objectif :

• On galère à faire plus de 1 mise en production par semaine

• On a beaucoup de régressions sur notre application

• On peine à créer de nouvelles fonctionnalités

⇒ Peut-être qu’il y a un problème d’archi.

Conseil 2️⃣ s’appuyer sur les dévs / archis

Ce sont eux les experts du sujet. Il faut apprendre d’eux, leur demander conseil et les appuyer si besoin sur cette thématique. Mais quelque soit ton rôle, tu dois pousser pour une bonne architecture.

C’est vrai si tu es designer, parce que l’architecture est liée à comment les informations sont organisées sur les interfaces.

C’est vrai si tu es Product Manager, parce que ton boulot c’est de créer une application de qualité et on a vu que c’était impossible avec une mauvaise archi.

C’est vrai si tu es QA, parce qu’une bonne application c’est une application qui doit être testable facilement et c’est à ça que sert aussi l’architecture.

Conseil 3️⃣ faire sa part du travail en tant que PM

En tant que Product Manager, tu es responsable de l’architecture fonctionnelle. Plus précisément, c’est toi qui maîtrise le processus suivi par l’utilisateur lorsqu’il est sur ton produit. L’enchaînement de toutes ces étapes, c’est ce qu’on appelle l’architecture fonctionnelle. Ça répond à la question : à quoi sert mon produit ?

Ensuite on décline cette architecture fonctionnelle pour créer les architectures techniques.

Conseil 4️⃣ pousser les approches Domain Driven Design

C’est un vaste sujet que je ne vais pas pouvoir traiter de manière exhaustive. Ça fera sûrement l’objet d’une prochaine édition de la newsletter.

Pour la faire courte, le DDD vise à faire dialoguer tous les acteurs du projet : tech, business, métier etc… L’enjeu derrière est de s’assurer qu’il n’y ait pas de quiproquos ou d’incompréhensions et que le monde technique soit cohérent avec le monde métier.

Ce genre d’activités permet justement d’améliorer l’architecture.

Conseil 5️⃣ être vigilant sur la dette technique

La dette technique est également un sujet très vaste que je ne pourrai pas traiter exhaustivement, en quelques lignes. Cela renvoie à l’ensemble des décisions prises lors du développement du produit et qui négligent des aspects de conception technique.

C’est très lié avec les enjeux d’architecture. Très souvent, quand on génère de la dette technique, c’est qu’on a négligé l’architecture.

Conseil 6️⃣ attention aux effets de mode (le sujet microservices)

Comme je l’évoquais plus haut, on a eu un peu la période de gloire des microservices où tout le monde disait que c’était incroyable. Puis il y a eu le retour de bâton. Finalement c’est pas si facile que ça, ni intéressant que ça.

Il faut se méfier des effets de mode. Comme toujours en informatique, il y a des choix qui font sens parfois dans un contexte ; et des choix qui ne font pas sens dans un autre contexte.

Conseil 7️⃣ aller lire quelques bouquins sur le sujet

Ce qui est cool sur les sujets d’archi, c’est qu’il y a des livres bien faits sur ces sujets sans lignes de code à l’intérieur ! Donc compréhensible si tu n’es pas développeur. Je conseille ces 3 ouvrages top :

• The software archi elevator

• Domain Driven Design distilled

• Design system interview

Conclusion

À dimanche prochain !

(trop bien avec le 14 juillet, on a un week-end de 3 jours)

Si tu es trop impatient pour attendre, tu peux :

• M'envoyer des actus, contenus ou rires qui ont animé ta semaine 💪

• Me contacter pour échanger sur l’architecture par mail ou par message LinkedIn 💪

• M'envoyer des feedbacks sur ce numéro, positifs... ou négatifs bien sûr ! C'est comme ça qu'on progresse 💪

• Partager la newsletter à des personnes susceptibles d'être intéressées 💪

Bon courage pour la semaine 😄 !

Victor