DEV Community: Olivier Maléa

🏆Quick-win : Fix erreur NETSDK1045 avec .net 7 preview

Olivier Maléa — Tue, 30 Aug 2022 11:15:00 +0000

Comment résoudre l'erreur : error NETSDK1045 The current .NET SDK does not support targeting .NET 7.0.

Dans un pipeline Azure DevOps, en utilisant le sdk .net6 dans une task de CI, aucun problème, tout fonctionne sans accroc, jusque là rien d'anormal.
L'extrait ci-dessous présente une task simple, issue d'un fichier yaml:

- task: UseDotNet@2
  displayName: 'Use .NET Core sdk'
  inputs:
    packageType: sdk
    version: 6.x
    installationPath: $(Agent.ToolsDirectory)/dotnet

Lorsque vous utilisez le sdk .net7 (à l'heure actuelle en état de preview), celui-ci causera une belle erreur :
error NETSDK1045: The current .NET SDK does not support targeting .NET 7.0.

Pour résoudre ce problème, c'est très simple: ajoutez le paramètre includePreviewVersions: true, comme détaillé ci-dessous:

- task: UseDotNet@2
  displayName: 'Use .NET Core sdk'
  inputs:
    packageType: sdk
    version: 7.x
    includePreviewVersions: true
    installationPath: $(Agent.ToolsDirectory)/dotnet

C'est gagné !

Pensez produit, pensez Vertical !

Olivier Maléa — Wed, 24 Aug 2022 09:06:00 +0000

L'informatique, dans une entreprise ou une structure d'activité(s) dont le cœur de métier n'est, justement, pas l'informatique, joue traditionnellement un rôle de support.
Bien qu'en constante augmentation, la place de l'IT dans l'entreprise se limite souvent à la réalisation de projets, ceux-ci n’affectant pas l’organisation en place puisqu'étant par essence ponctuels.
Cependant, les méthodes de gestion de projet, la culture projet, n'ont cessés d'évoluer, à tel point qu'il devient stratégique d'avoir une entité dédiée au sein de l'entreprise, et donc un fonctionnement plus adéquat.

Dans cet article, je vais présenter les principes verticaux permettant de fluidifier l'activité d'un SI.

Projet? Produit? On fait quoi chef ?

Bon déjà, commençons par définir ces 2 notions, cela permettra d'y voir un peu plus clair et d'avoir une base solide.

A ma gauche : le projet…

Un projet est un ensemble finalisé d’activités et d’actions, réalisées par une équipe dédiée sur une plage de temps définie, se traduisant par un ou des livrables.
ITIL4 définit les projets comme l’un des moyens d’introduire des changements significatifs au sein de l’organisation. Ils peuvent être définis comme structures temporaires créées dans le but de livrer un ou plusieurs livrables (ou produits) selon le dossier business convenu.
Un projet se caractérise donc par un début et une fin, est par essence unique et doit aboutir à un résultat tangible, mesurable et appréciable.
Je ne m'attarde pas sur la constitution des équipes, la nécessité d'avoir une équipe dédiée (parfois plusieurs) à chaque projet et l'organisation autour d'un chef de projet, ce n'est pas le propos de cet article.

… Et tout autour, le produit

Sur le plan marketing, un produit est un bien ou un service vendu par une organisation afin de satisfaire un besoin. Un produit peut être physique ou immatériel.
ITIL4 définit un produit comme la configuration des ressources d'une organisation conçue pour offrir de la valeur à un consommateur.
Un produit ne possède ainsi pas de notion de temporalité mais repose sur la notion de valeur ajoutée, son utilité est sa raison d'être.

Et où tout cela nous mène ?

En gros, le monde de l'IT est assez traditionnellement orienté projets, c'en est presque devenu un gros mot.
Le développement logiciel est souvent un acte ponctuel, avec un début et une fin ainsi qu'un livrable.
Ok ! Cela colle avec les caractéristiques précédemment définies d'un projet, sauf que …
Une fois livré on arrête tout ? On fait quoi des équipes ? On laisse notre code vivre sa vie tout seul dans son espace dédié, un genre de retour à la nature en somme ?
Ah ça y est je l'ai : on lance un projet pour le maintenir et le faire évoluer ou - attendez c'est génial ! - plusieurs projets chainés pour le faire évoluer et le maintenir entre 2 - on tient un truc c'est sûr -.
En fait, c'est plus simple.

Attends, toi là bas, qui a dit d'un air narquois mais très confiant, on laisse le support et les opérationnels se débrouiller, tu sors.

A la base, les organisations développent des softs dans un but précis il me semble : satisfaire un besoin, et accessoirement en tirer un usufruit (gagner de l'argent plus trivialement).
On y arrive, un logiciel PEUT donc être considéré comme un produit à part entière, il possède certes un cycle de vie mais peut aussi être considéré comme un élément intemporel puisque sa durée d'exploitation est très difficilement appréciable.

Ceci étant dit, on arrive doucement vers le principal problème induit par une organisation projet : le cas par cas.

Horizontal Limit

En effet, nous avons précédemment vu qu'un projet suppose une équipe dédiée, comme il s'agit d'un processus ponctuel, il est logique de monter une équipe pour ce besoin.
Cette équipe sera d'ailleurs présente durant toute la phase de création de la solution et sera reventilée la plupart du temps une fois la solution livrée.
Au cours d'une étude publiée sur researchgate, l'IEEE Computer Society précise que les méthodes logicielles traditionnelles encouragent la division horizontale des membres du projet en équipes fonctionnellement séparées.
Cette division engendre la création d'équipes de développement, d'assurance qualité et d'opérationnels, parfois d'équipes prenant en charge les spécifications.
Cette séparation augmente la durée du cycle de développement en raison des transitions nécessaires entre les différentes équipes.
Le bon vieux principe de silotage.

En résumé : on va monter une équipe pour concevoir et confectionner une solution technique répondant à un besoin, on peut donc parler de produit. On va sûrement devoir monter d'autres équipes pour valider les livrables et gérer l'exploitation. Pour que le projet réussisse, toutes les étapes doivent être complémentaires et apporter une valeur ajoutée.

Plusieurs problèmes apparaissent d'emblée :

Chaque équipe aura forcément son mode de fonctionnement, spécifique à son cadre de compétences, et donc ses outils et processus dédiés;
Chaque équipe limite sa responsabilité et réalise ses tâches en fonction de son cadre technique;
La communication entre les équipes devient complexe;
Il devient difficile de gérer le transfert de connaissances fonctionnelles et la montée en compétences techniques.

Bref, il va falloir fournir beaucoup d'efforts pour assurer une coordination efficace et cela aura forcément un coût, en plus du fait qu'on aura tendance à se couper d'une forme de fluidité.

Levons un doute : je ne prétends pas que l'organisation projet est à jeter à la poubelle, elle s'avère toujours efficace et pertinente lorsque le sujet répond aux critères précédemment énoncés d'un projet.

Il est temps de voir quels seraient les avantages d'une organisation orientée produit, ou même catalogue de produits.

C'est là que tout se produit

Commençons par une maxime de l'armée US, les 6 p : Une Préparation ~~Parfaite~~ Préalable Permet de Parer aux Piètres Performances.

En adoptant une approche orientée produit, notre organisation va mettre en place et coordonner plusieurs choses afin de préparer un lancement réussi : la qualité du produit, l'écosystème technique, les outils favorisant la vélocité, préparer le delivery et l'intégrer dans le cycle de développement, définir la norme technique, et au final, rentrer dans un cercle vertueux permettant de s'améliorer continuellement.
L'équipe projet devient une équipe organisée verticalement: terminée la succession de rôles, en reposant sur les principes de DevOps, permettant justement de casser les frontières, notre équipe produit va couvrir de multiples compétences, on parle de Crossfunctional Team.

Stream-aligned teams

Dans leur ouvrage intitulé Team Topologies, Matthew Skelton et Manuel Pais définissent ce type d'équipe en tant que Stream-Aligned Teams et l'expliquent comme suit :
Il s'agit d'une équipe alignée sur un flux de travail unique et précieux ; il peut s'agir d'un seul produit ou service, d'un seul ensemble de fonctionnalités, d'un seul parcours utilisateur ou d'un seul utilisateur. De plus, l'équipe est habilitée à créer et à fournir une valeur client ou utilisateur aussi rapidement, en toute sécurité et de manière indépendante que possible, sans nécessiter de transfert à d'autres équipes pour effectuer certaines parties du travail.

Architecture en continue et construction d'équipes

Pour aller plus loin, le 1er principe de l'architecture en continue est explicite : Architecturer des produits : l'architecture des produits est plus efficace que la simple conception de solutions ponctuelles aux projets et concentre l'équipe sur ses clients.
Il s'agit donc d'évoluer depuis une gestion de projets vers une gestion de produits.
D'ailleurs, cela va paraitre contre intuitif, mais le 6ème principe de l'architecture en continue suppose de modéliser l'organisation des équipes après la conception du système à mettre en place.

En effet, une fois la phase d'idéation du produit finie, c'est à dire le moment où on réfléchit et conçoit l'idée même du produit, la phase de définition du produit va permettre de déterminer les exigences fonctionnelles et les exigences non fonctionnelles, en architecture continue on parle de Quality attributes.
Les attributs de qualité sont :

Adéquation fonctionnelle;
Efficacité des performances;
Compatibilité;
Fiabilité;
Convivialité;
Sécurité;
Maintenabilité;
Portabilité;
Robustesse;

J'en oublie forcément …

Ces derniers, une fois triés et priorisés vont driver la conception du système, c'est à partir de là qu'on pourra définir les équipes puisqu'on sera désormais capable de cartographier le spectre de compétences nécessaires à la confection de notre produit.

Valeur ajoutée d'une équipe produit

De fait, on va avoir tendance à créer des synergies dans l'équipe, avoir une méthode de travail fluide et sans à coups.
Cela aura pour effet de concentrer les efforts vers un but commun, compris de la même manière par tous les membres de l'équipe, et non pas orienté compétences et objectifs individuels.
Plus pragmatiquement, ce changement de paradigme va permettre de nous rapprocher de ce qui produit la valeur, de considérer les éléments à construire dans leur intégralité et non pas simplement comme des features ou des fonctions à développer.

On intègre ainsi le concept de Value Stream Mapping provenant de Lean, permettant d'effectuer une cartographie de toutes les étapes à valeur ajoutée et sans valeur ajoutée qui amènent un produit d'un état initial à un état final, et donc de prioriser l'effort.

De même, on a tendance à mettre en place des outils prenant en charge le fonctionnement de manière plus globale et permettant d'éviter la dispersion.
En termes de résultat, cette organisation favorise la vélocité car la livraison et la validation de contenu se font au plus tôt et en continue, les boucles de rétroaction sont plus efficaces et l'automatisation des process (build, test, provisioning d'environnement, configuration, déploiement, monitoring, ...) est rendue possible car intégrée directement dans la conception du produit.

Une précision pour ce dernier point : les environnements mis en place font partie intégrante du produit et doivent être pensés, développés et mis à disposition par l'équipe elle-même le plus tôt possible.

Sur le long terme, on pourra même orienter notre organisation vers des pratiques type ProductOps, mettant le client au cœur des débats et permettant de collecter des informations utiles au plus tôt et de manière continue.

Finalement, ce qui nous intéresse est la mise en place de processus concrets favorisant :

la détermination, la priorisation et le développement des "flux de valeur" fournissant un service maximisé à l'utilisateur, et donc une augmentation de la qualité perçue;
la diminution de la charge cognitive pour l'équipe en place car les spécifications ont tendance à être exprimées de manière plus claire et plus directe et sont englobées dans un tout cohérent;
un gain en modularité, flexibilité et indépendance, en effet l'équipe se concentre sur la production de valeurs et l'architecture est totalement tournée vers le produit plutôt que le reflet d'une organisation, comme prédit par la loi de Conway;
une forte capacité à revenir sur les éléments pauvres en valeur ajoutée ou sur les erreurs (principe de fail fast), ou intégrer au plus tôt les retours utilisateurs;
la suppression des silos de compétences et la promotion d'un travail plus collaboratif;
une accélération du Time-To-Market significative.

J'ai glissé chef

Comme il faut bien conclure, je dirais simplement que le sujet est loin d'être nouveau, Marty Cagan en parle d'ailleurs dans ses deux livres Inspired et Empowered.
Evidemment, ces principes ne sont pas applicables systématiquement, il est important de bien comprendre les enjeux et les apports sous-jacents ainsi que les modifications structurelles qu'ils supposent, autant que le changement de culture induit.
Vu l'intérêt stratégique que peuvent avoir les principes de verticalité, des articles plus spécifiques pourraient bien suivre celui-ci, très généraliste, alors stay tuned !

Retour d'expérience : 🚀comment j'ai "révolutionné" un SI

Olivier Maléa — Sun, 21 Nov 2021 14:30:00 +0000

Sous ce titre quelque peu accrocheur se cache en réalité un projet ambitieux de longue haleine et complexe assorti de beaucoup de décisions stratégiques !

Cet article est l'occasion de décrire une situation, qui à mon sens, n'est pas unique ou isolée, ainsi que les solutions possibles et les transformations à prévoir.

Je vais m'efforcer d'être le moins technique possible, d'autres articles suivront pour ceux qui en sont friands 😊.

Au début il y avait le contexte

J'ai été sollicité par une entreprise dont l'activité n'est pas l'informatique, sur mon expérience d'architecte logiciel, pour mettre en place un nouveau socle technique afin de moderniser plusieurs éléments de son écosystème logiciel.

J'ai dû appréhender un passif de plus de 10 ans, beaucoup de petites applications fonctionnant de manière isolée, plusieurs outils web dédiés à la gestion de l'activité métier.
L'entreprise avait la culture du PGI (Progiciel de Gestion Intégré ou ERP en Anglais) de ce fait, tout l'applicatif en place était lié par un tronc commun: une base de données monolithique.

Les différentes applications, des sites web, avaient un autre tronc commun: les langages tournaient tous autour du .net, ce qui m'a immédiatement intéressé puisqu'il s'agit de ma spécialité, surtout le .Net Core.

Puis vinrent les problèmes

Et quels étaient les problèmes ?

Beaucoup !

Mais encore ?

Eh bien puisqu'il faut commencer par quelque chose, je dirais en premier le facteur humain.

Le facteur humain

L'équipe était très (trop !) petite: une 2-pizza team 🍕🍕 … pour l'ensemble de l'écosystème.

Pour rappel, le concept de 2-pizza team est l'émanation de Jeff Bezos, CEO d'Amazon, affirmant que la taille idéale d'une équipe correspond au nombre de personnes que l'on peut nourrir avec 2 pizzas, soit entre 5 et 10 personnes.

Bon, cette donnée est relative et dépend tout de même de l'appétit des protagonistes mais passons …

L'équipe était organisée en silos techniques:

Les techniciens IT, en charge des infrastructures et du réseau ;
Les développeurs en charge de … dois-je vraiment préciser ?

Sur le plan opérationnel, l'empirisme était la règle: tout se faisait en réaction plutôt qu'en prévision.

En effet, les demandes provenant des utilisateurs étaient captées par des experts métiers officiant en tant que support, externes aux équipes informatiques, ce qui induisait une forme d'urgence systémique puisque la majorité de la valeur produite ne consistait qu'au règlement des problèmes rencontrés.

Le fait que chaque pôle de compétences travaillait en silo ne facilitait d'ailleurs pas la communication et l'organisation était analogue: fermée, compliquée et incapable d'évoluer.

L'organisation

Le fonctionnement en silo est le fait que chaque équipe (ou département, ou même service) exerce son activité, relative à sa spécialité, sans se soucier de l'activité des autres.

Pour aller à l'essentiel, le principe de silos, s'il permet de bien délimiter les compétences et donc (logiquement ?) les responsabilités de chacun, n'est pas réputé pour ses forces en matière de communication, de synergies entre les équipes et de capacité d'adaptation sur le long terme.

Sur le plan de la méthodologie en place, Il n'y en avait pas forcément: la production était simplement portée par le besoin «le plus pressant» et quelques projets sporadiques visant à ajouter des fonctionnalités nouvelles ou des évolutions nécessaires.

Pour accompagner cette activité et donner du liant, des outils étaient bien évidement en place: ticketing, actitivity-tracker et pour le reste … échanges de mails.

En termes de sociologie d'équipes, le fait d'être isolé rend les gens méfiants, suspicieux de la qualité et du travail des autres, peu impliqués dans un effort collectif et tout cela se ressentait, une forme de tension existait entre chaque service et l'activité peinait à atteindre un optimum.

De même, il était compliqué de déterminer le niveau d'implication et de responsabilité de chacun puisque l'activité était plutôt répétitive et monotone, bref plus contrainte que stimulante.

Le manque de méthodologie clairement définie générait également un manque de traçabilité, tant dans les éléments de travail que dans l'activité de chacun.

La technique

Sur ce point, l'écosystème présent était très … plurale.

Effectivement, beaucoup de langages issus du .Net pour la plupart ont été employés à différents moments de l'histoire de l'entreprise, citons tout de même de manière non exhaustive et non ordonnée: ASP classic, ASP.NET MVC 5, ASP.NET WebForms.

Une multitude d'applications consoles en .Net framework 4.0 à 4.8 revêtant la forme de services Windows, quelques modules PHP, et quelques WinForms venaient compléter ce panel.

Pour ajouter un peu de complexité à cette diversité de langages, les développements ont été, dans le passé, confiés à des équipes qui n'existent plus, il n'y avait bien entendu que le strict minimum en termes de documentation et certains applicatifs n'étaient même pas publiés dans un dépôt de code.

Pour ce qui est des dépôts de code, des partis pris radicaux quant aux bonnes pratiques d'ingénierie logicielle et des principes d'industrialisation ne rendaient pas forcément le code disponible exploitable.

En ce qui concerne le code en lui-même, plusieurs éléments m'ont sautés aux yeux immédiatement:

Absence totale de tests techniques (unitaires, intégration, …), de même que pas de tests de qualification ni de protocole de non-régression mais cela est hors scope si on se place sur le plan technique (dis donc ! tu ne serais pas en train de reproduire un silo idéologique là ?) ;
Niveau de maturité du code très hétérogène ;
Aucune règle de confection de code (organisation des éléments au sein des classes, règles de nommage, nomenclatures) ;
Aucun patron de conception guidant les développements ;
Une complexité cyclomatique, c'est-à-dire le nombre de chemins « linéairement indépendants » empruntable au sein d'une fonction, proche de l'incroyable ;
Une interdépendance élevée entre les différents blocs de code ;
Des couches organisationnelles peu ou pas du tout déterminées ;
Non-respect des principes d'ingénierie logicielle (SOLID), redondance, code et fonctions dupliqués ;
Des solutions trouvées à des problématiques spécifiques plus proches du bricolage (tiens, c'est à la mode ça en ce moment …), voir du POC (Proof of Concept), que de vrais éléments techniques robustes et maintenables;
Sur le principe de l'ERP: recours à une super base de données, un monolithe persistant sur lequel TOUS les applicatifs venaient se raccorder, ainsi qu'un couplage fort avec celle-ci (c'est mal !) ;
Une utilisation très limitée des possibilités relationnelles de cette base de donnée SQL, beaucoup d'ambiguïté dans les noms de table / colonne ;
Last but not least: pas d'Api's !!!!

La somme de ces éléments rendait les applicatifs très difficiles à maintenir, faire évoluer, et tout reposait sur la connaissance de l'homme du métier puisqu'aucune documentation ne venait assortir le code.

Pour parachever cet instantané de la situation technique, le système de mise en production était très artisanal, basé sur des outils dépassés et le recours systématique à une intervention humaine sur les serveurs plutôt qu'une judicieuse et millimétrique automatisation…

Et au milieu … l'analyse

Tout d'abord, je souhaite rappeler et mettre en avant le fait que cette entreprise n'est pas spécialisée dans le domaine informatique, ce dernier ne jouait jusque-là qu'un rôle de support d'activité, comme dans bien des entreprises d'ailleurs.

Le problème avec cette approche est relativement simple: la croissance et le développement de l'entreprise ont rendu ce rôle de support inadéquat. La DSI n'a jamais pris la pleine mesure de l'évolution et n'a jamais adapté son organe à la réalité de la situation qui imposait un nouveau champ d'action: grandir et devenir une vraie entité produisant de la valeur et du business, et non plus un simple support.

First Principle

Mes premières conclusions ont été dans ce sens et en se référant au «First Principles Thinking» - basiquement en me limitant à poser la question Pourquoi ? - j'ai pu réduire le problème à quelques questions, que voici, livrées avec leurs réponses:

Pourquoi cette faiblesse technique ?
- Manque de connaissance architecturale et lacunes en ingénierie logicielle;
- Manque d'ambition et d'engagement pour changer les choses;
- Manque de confiance en la perspective d'un socle technique moderne, cloisonné à quelques technos mais fortement maîtrisé ;
- Manque de qualité dans le code permettant de déceler et d'anticiper les anomalies ;
- Une technique vieillissante incapable d'accompagner la croissance de l'entreprise et de répondre à de nouveaux défis, ou tout simplement de traiter l'information de manière optimale.
Pourquoi ce fonctionnement en silos et ce manque de communication ?
- Pas de méthodologie clairement établie ;
- Pas assez d'interactions entre les équipes et donc une méconnaissance de l'«Autre»;
- Des outils peu adaptés et peu claires dans leur fonctionnement;
- Des ambiguïtés sur les rôles de chacun;
- Un manque de confiance de la direction générale envers la technique ainsi qu'une culture du service opérationnel quelque peu dépassée.
Pourquoi ces difficultés à produire et publier du code ?
- Pas de process de livraison clairement détaillé ;
- Pas ou très peu de processus de validation des livrables, de même qu'un manque de clarté pour ces derniers ;
- Pas d'automatisation (CI / CD) et recours bien trop prononcé à l'humain (donc à ses faiblesses et limites !) ;
- Équipe créant de la valeur totalement sous dimensionnée, dépassée par les événements et travaillant la plupart du temps en mode «pompier».

Une dernière question subsistait, éloignée du pourquoi mais tellement centrale: qu'en est-il de l'utilisateur final ? Tous ces problèmes entachent-ils l'utilisation des différents outils et ces derniers répondent-ils aux attentes des utilisateurs (le personnel de l'entreprise en grande partie)?

Fort de cette analyse, j'ai raisonnablement pu déterminer plusieurs axes d'amélioration, voire de rupture.

Et suivirent les solutions

Organiser le changement technique et technologique

L'évidence était là: il fallait augmenter le niveau de maîtrise des technologies travaillées tout en capitalisant sur les compétences existantes.

En essayant de rationnaliser au maximum, il fallait conserver le savoir-faire existant et donc rester sur les technologies afférentes au .Net.

Il fallait, dans le même temps, s'inscrire dans la modernité et mettre en place un nouveau socle technique, moderne et qui serait également l'opportunité d'une architecture logicielle répondant à certaines caractéristiques, notamment les principes du Reactive Manifesto:

Source https://www.reactivemanifesto.org

Ceci pour plusieurs raisons:

Le développement de l'entreprise induit d'avoir une solution technique scalable et extensible ;
Plusieurs applications, avec chacune leur responsabilité et portée spécifique, vont émerger de cette analyse et il faudra les rendre inter-communicantes, quoi de mieux qu'une plateforme échangeant via un agent de messages pour assurer cette fonction !
Il faut, à termes, être capable, de gérer au mieux les anomalies, idéalement les anticiper, à minima ne pas perdre d'activité et pouvoir débloquer des situations complexes ;
Les différentes applications doivent être totalement user-centric, c'est-à-dire basé sur l'analyse des comportements des utilisateurs, et favoriser l'expérience de la meilleure manière possible ;
Apporter des briques rendant possibles l'innovation ;
Enfin, la solution technique doit permettre des livraisons rapides, sans faille et à un rythme soutenu, sur une plateforme offrant souplesse et adaptabilité, probablement hébergé via un cloud …

J'avais dès le début en tête une approche basée sur la mise en place d'une nouvelle stack technique, simple mais maitrisée: .Net Core + Angular.

.Net Core

Ce langage permet de développer des applications de haute qualité, modernes, rapides et en accord avec la philosophie des micro-services.

Il met rapidement à disposition les dernières fonctionnalités développées, communautaires ou éditoriales, et permet une grande modularité, il est également totalement tourné vers l'open-source et le cloud.

.Net Core permet de mettre en place relativement facilement une Architecture Orientée Services (SOA) d'entreprise: les données seront désormais exposées via des Api's.

Cela constitue donc l'opportunité de conceptualiser une batterie de micro-services, totalement orientés métier, propriétaires et responsables pour chacun de leur système de persistance (ce qui change radicalement du paradigme existant).

Pour le volet inter-communicabilité, il a fallu mettre en place un broker de messagerie (RabbitMq) assorti d'un framework accélérant les développements (Mass-Transit) et facilitant la concurrence car il repose sur TPL (Task Parallel Library).

Angular

Afin d'homogénéiser les pratiques sur le plan du web, l'expérience utilisateur et la captation des données, il fallait simplifier l'existant, apporter une forme d'unicité dans l'offre de l'entreprise.

En l'état, les solutions traditionnelles proposées par la stack - vieillissante - .Net (asp.Net MVC assorti du moteur de vue Razor, WebForms ou encore ASP Classic) ne donnaient pas satisfaction et n'accompagneraient pas une montée en gamme et en technologie.

D'autant plus que les langages employés imposaient un fort couplage avec le back-office. Il fallait donc assurer un cycle de vie pour les applications front indépendant de celui du back, limiter autant que possible ce que j'appelle l'hybridation, à savoir les langages responsables à la fois du back et du front.

J'avais l'idée qu'il fallait idéalement partir sur une solution front mature, modulaire, évolutive et «architecturable», cela dans une double optique: organiser la rupture technologique et unifier le processus de création web.

Angular a pour particularité de reposer sur TypeScript, un langage typé objet compilant du javascript, proche du C#, et d'être très modulaire puisque basé sur une architecture … en modules !

Il dispose d'une très forte communauté et est très bien documenté, tout en proposant un niveau de maturité et de fonctionnalités très élevé et en plus de tout cela, NG (son petit sobriquet) est mis à jour fréquemment, peut-être trop depuis 2 ans … mais je m'emballe.

Le dernier atout d'Angular est qu'il peut être monté en Micro-Front end moyennant recours à quelques frameworks dédiés. Je pense que nous avons là une très bonne solution front modulaire et permettant de faire beaucoup de choses.

Et tu fais quoi de l'existant ?

Une question est effectivement tout de suite apparue: que faire de l'existant ?

Eh bien je me suis tout de suite fixé comme ligne de conduite de ne pas modifier cet existant, ou du moins le minimum possible, ce qui a rapidement induit une gouvernance claire:

Développement d'un site vitrine et du back office organisé en micro-services ;
Étranglement applicatif pour une partie de l'existant ;
Maintenance thérapeutique sur les éléments ne supposant ni reprise ni évolution.

Je vais présenter rapidement les différents principes mis en place sans toutefois apporter trop de détails, cela fera l'objet de futurs articles (un peu de teasing ne fait jamais de mal !).

Site vitrine

Le développement de l'application vitrine, un site web, a été l'occasion de mettre en place une architecture signature qui encadrerait les développements, a permis de développer un maximum de micro-services tout en intégrant des tests techniques ainsi que l'écosystème permettant de gérer le flux produit: des pipelines de CI / CD via Azure DevOps assorti d'une stratégie d'hébergement cloud (Azure).

Ce chantier a été l'opportunité, à travers l'architecture que j'amenais et le mentoring, de faire monter les équipes en compétence sur des techniques que j'avais pris l'habitude d'utiliser:

TDD (Test Driven Development) ;
Code First en utilisant Entity Framework Core ;
Event Sourcing et CQRS, puis MDA (Message Driven Architecture) ;
In-Memory testing (In-memory Database, proxy http, Web-Application Factory).

Mais également de nouvelles choses pour moi, comme BDD (Behavior Driven Development) via SpecFlow (.Net Core) et Cucumber (Angular) qui reposent tous 2 sur le langage Gherkin 🥒 et permettent d'écrire et développer des tests typés « comportement » assez facilement.

Dans cet esprit, une équipe a été créée afin de mettre en place le nouvel écosystème, nous pouvons qualifier celle-ci de platform team pour faire référence aux Teams Topologies, puisqu'elle a été en charge de toute la mise en place:

Utilisation de l'architecture que j'avais définie et développée;
Écosystème micro-services «Cloud-ready» pour lequel il a fallu définir et créer les environnements, les pipelines d'intégration et déploiement continue;
Création des «Apis d'équipe»: pages Swagger pour les micro-services, documentation via un wiki dédié dans Azure DevOps;

Stratégie d'étranglement applicatif

Si l'application vitrine visait à remplacer son pendant existant par une nouvelle application, un traitement différent a été choisi pour les autres éléments de l'écosystème (des sites web) nécessitant une reprise totale: l'étranglement applicatif.

L'étranglement applicatif est un concept émanant de la démocratisation des micro-services, celui-ci repose sur un passage organisé et cadencé de pans entiers d'applications, systèmes de persistance vers une nouvelle solution technique, il permet de moderniser graduellement l'existant tout en ne dégradant pas l'activité.

Bien évidemment, cette technique suppose de pouvoir échanger les données entre l'ancien et le nouveau paradigme, il a donc fallu conceptualiser et développer … un micro-service raccordé sur la base de données existante capable de détecter automatiquement toute modification de données et de recevoir les modifications provenant des autres services.

Cette fonctionnalité repose sur l'usage massif de l'event-sourcing, en gros de transmettre une information une fois qu'un événement est détecté, et l'échange de messages entre les différents micro-services présents.

Du coup, la mise en place technique résultant des développements du site vitrine rendait possible beaucoup de choses.

A termes, Il n'y a donc plus deux paradigmes distincts (le «legacy» et le «new») mais bel et bien un seul proposant une multitude d'éléments cohérents et inter connectés.

Pour le reste, il fallait rapidement rendre l'existant industrialisable (sur le même plan que l'application vitrine) et une phase de migration vers des dépôts Git et une gestion de flux CI / CD via Azure DevOps a été planifiée et exécutée, ce qui a évidemment induit une refonte de l'équipe de développement.

Très rapidement, pas mal de retour d'expériences sur ces éléments ont permis d'apporter des ajustements sur le site vitrine avant qu'il ne passe en production, ce qui est une forme de capitalisation relativement luxueuse: savoir à l'avance ce qui fonctionne mal et pouvoir l'ajuster.

Organiser le changement organisationnel et méthodologique

Refonte de l'équipe de développement

Si l'on reprend le principe de «charge cognitive d'une équipe» exposé par Matthew Skelton et Manuel Pais dans leur ouvrage Team Topologies, avoir une seule équipe pour gérer et maintenir un pool d'applications parait totalement sous-dimensionné.

Il a donc fallu redéfinir l'équipe en place et en créer une nouvelle, en adéquation avec le nouveau socle technique mis en place, de manière à avoir une charge cognitive beaucoup plus raisonnable.

Donc, comme exposé dans le paragraphe précédent, cette refonte du SI tourne autour de 2 équipes: l'une (historique) gérant les applications existantes (le legacy) et l'autre dont l'activité tournait autour de la mise en place du nouveau socle technique et d'un site vitrine.

Voyons maintenant comment celles-ci fonctionnent.

L'organisation

Il a fallu mettre en place une organisation capable de supporter les nouvelles contraintes techniques.

Un nouveau service en résulte, plus proche à la fois du besoin utilisateur, des développements et de l'opérationnel.

Pour ce faire, l'approche DevOps a été la ligne directrice, terminé donc le cycle de vie et place au flux continu, exit les silos, bienvenu la collaboration !

Les équipes sont désormais constituées de développeurs, de l'AMOA (les fameux experts métiers) ainsi que de business-analysts et de nouvelles compétences propres à l'infrastructure et au réseau, applicables dans un domaine Cloud.

Cela induit évidemment la destruction des silos par compétence et laisse place à un fonctionnement où tout est plus simple, mieux huilé, tout le monde travaille dans un seul but: produire de la valeur et donner satisfaction aux utilisateurs.

En termes d'outils, là aussi, une forme d'harmonisation apparait puisque les outils existants ont été remplacés par un seul outil, central, suffisamment puissant et modulaire pour être la colonne vertébrale de l'activité sans toutefois être chronophage dans sa gestion.

J'ai opté pour Azure DevOps, j'aurai pu utiliser autre chose mais il se trouve que je souhaitais capitaliser sur mes expériences, mon savoir, et c'est un outil que je maîtrisais déjà.

Je savais qu'il nous permettrait de mener notre barque efficacement et qu'il nous accompagnerait dans nos évolutions.

Il a fallu une période de mise en place puis de training et d'acquisition afin que tout le monde s'adapte et devienne autonome, efficace avec cet outil.

Nous avions désormais les équipes (même si des recrutements étaient nécessaires pour acquérir les compétences manquantes), les outils et le fonctionnement drivant notre activité, ne restait plus qu'à définir quelle méthodologie allait rendre tout cela cohérent et efficient.

La méthodologie

Il nous fallait être efficace, en capacité de produire vite … et beaucoup (un socle technique complet développé en moins de 3 mois avec une équipe réduite !), et gérer un rythme assez soutenu.

Cela supposait une méthodologie adaptée.

J'avais le pressentiment que Scrum était le candidat idéal, sentiment partagé par mon Directeur de projet ainsi qu'une grande partie de l'équipe.

Je ne m'attarderai pas sur Scrum, beaucoup d'articles le dépeignent déjà, mais son apport a été immédiat:

Gain en flexibilité dans les développements ;
Meilleure gestion des ressources et ajustement des éléments à produire ;
Retours d'expérience rapide ;
Engagement de chacun.

Ce dernier point est important car, le niveau d'adhésion avant cette refonte était très bas, il n'y avait aucun projet ambitieux et aucun challenge dans l'activité.

L'engagement de tous a permis de se remobiliser, d'avoir un objectif tangible, complexe et difficile à atteindre mais finalement gratifiant pour tout le monde.

De plus l'activité devenant beaucoup plus rationnelle, avec des objectifs et des temps forts, il était désormais possible de voir des résultats rapides, ce que l'on appelle des quick-wins et de redonner une note positive à l'activité informatique.

Le mot de la fin

Pour finir, je citerais simplement Albert Einstein pour qui «La folie, c'est de faire toujours la même chose et de s'attendre à un résultat différent » ainsi que Bill Campbell (The Trillion Dollar Coach): «Le leadership consiste à reconnaitre qu'il y a de la grandeur en chacun et votre travail consiste à créer un environnement dans lequel cette grandeur peut émerger».

J'ai eu à cœur d'appliquer ces 2 maximes et d'en faire une réalité tangible.

J'espère que ce retour d'expérience, même s'il est très en surface pourra donner des pistes à toute personne se retrouvant dans une situation analogue.

Je finirai en disant que rien n'est possible quand on essaye d'avancer seul et qu'il faut s'efforcer de créer des synergies entre les hommes et les outils disponibles.