Actuellement, la plupart des applications se reposent fortement sur les opérations Input/Ouput (I/O). Ce type d’opération inclut le téléchargement du...
15 avril 2022
Méthode SOLIDITE – Faire évoluer son projet : 8 bonnes idées à nuancer
Pour un projet à la dérive, des experts proposent souvent des solutions miracles. Elles ne sont pourtant pas suffisantes et peuvent même entrainer des situations plus dangereuses encore.
Voici les solutions proposées le plus souvent par les architectes :
1 – Auditer
L’audit seul ne résout rien, il n’est qu’un bilan du passé, une photo. L’audit donne des éléments factuels sur la complexité, sur les technologies et leur éventuelle obsolescence. Les conclusions de cet audit peuvent donner des pistes mais ce ne sont que des conjectures.
Connaitre son système, connaitre les imbrications, c’est la base mais ce n’est pas suffisant.
2 – Documenter
Comme pour l’audit, la documentation n’est qu’un indicateur : seule, elle ne solutionne pas le problème.
Même la meilleure documentation du monde ne résout pas un interblocage. Au mieux la documentation facilitera la montée en compétence. Elle peut éventuellement permettre une recherche plus rapide des impacts d’une mise à jour.
Cependant, il ne faut pas oublier qu’une documentation obsolète est pire que l’absence de documentation : en effet, de mauvaises informations entrainent de mauvaises décisions.
Documenter est essentiel mais ce n’est pas suffisant.
3 – Réécrire
Réécrire coûte cher et peut créer plus de problèmes que de solutions.
C’est pourtant la solution la plus populaire. La réécriture est souvent le remède conseillé par les architectes démunis, qui ne savent pas par quel bout aborder le problème. Ils préconisent alors de repartir de zéro, tout reconstruire, tout redévelopper.
Malheureusement, ces reconstructions ont des revers conséquents. Tout D’abord, reconstruire est très coûteux, à la fois en temps et en budget.
Ensuite, « l’effet tunnel » qu’engendre une réécriture importante d’un SI est souvent redoutable.
Enfin, repartir de zéro, c’est peut-être créer un nouveau sac de nœuds (différent de l’existant mais un sac de nœuds quand même).
4- Code et Cloud Agnostiques
L’agnosticisme est souvent plus complexe, plus coûteux mais pas obligatoirement plus avantageux.
En plus de réécrire, certains experts recommandent par défaut d’écrire du code « agnostique ». Une application en code agnostique permet de choisir a posteriori le type de machine sur lequel on veut l’exécuter (Windows, Mac, Linux…). On peut également déployer à loisir sur n’importe quel Cloud provider (Azure, AWS, GCP, On Premise…). On parle alors de Cloud agnostique.
L’agnosticisme du code ou du provider web semble une idée géniale. Mais parfois, les idées « géniales » ne sont pas si bonnes qu’elles en ont l’air. Tous ceux qui ont déjà tenté la manœuvre le savent déjà : ce n’est jamais aussi simple que prévu.
Même le code le plus agnostique nécessite de nombreux ajustements pour effectuer la bascule vers le nouvel hébergeur ou un type de serveur différent. Il faut également que la nouvelle configuration hébergeur / serveur soit maitrisée. De plus, l’écriture d’un code agnostique est généralement plus complexe, plus longue et donc plus chère. Enfin, écrire un code agnostique est souvent moins performant qu’un code en technologie native.
Réussir l’agnosticisme demande des ingénieurs avec nettement plus d’expérience et de très nombreuses compétences de pointe. En ces périodes où le recrutement est difficile, est-il nécessaire de rajouter une difficulté supplémentaire et chercher des perles rares, des « moutons à cinq pattes » ?
Le choix d’un code agnostique doit être réfléchi. Il existe des besoins spécifiques où son implémentation est avantageuse, mais le choix ne doit pas suivre un effet de mode ou un caprice de développeur.
Par ailleurs, écrire du code agnostique revient en réalité à réécrire (cf. point précédent).
5 – Appliquer une nouvelle méthode agile
Changer de méthode de gestion de projet peut être une bonne chose mais sans volonté de casser les nœuds, c’est surtout un pansement sur une jambe de bois.
On peut se plier à des nouvelles méthodes : DevOps, TDD, DDD, Agilité, Scrum, Kanban, etc. Mais ces dernières ne changeront pas l’existant directement.
Comme pour la réécriture, même la meilleure méthode ne résoudra pas d’un coup de baguette magique les intrications du Système d’Information. Elles n’empêcheront pas les interdépendances de se créer ni ne supprimeront celles existantes.
Par ailleurs, des projets sont gérés d’excellente façon avec des méthodes pourtant “archaïques” comme des cycles en V. Dans le même temps, des projets agiles échouent sans que la méthode ou son application puisse être remise en cause.
Les méthodes agiles ne permettent que le suivi des tâches. Il faut une volonté et une méthode pour ajouter des tâches de refactoring et de suppression de dépendances au backlog agile.
6 – Recruter / Remplacer les équipes / Former
Recruter si le Système d’Information est en piteux état est périlleux, surtout en période de forte concurrence de recrutement sur le marché informatique.
Des technologies obsolètes, un système complexe et peu de perspectives intéressantes sur le projet constituent autant de freins pour attirer les meilleurs éléments.
Remplacer des personnes qui ne donnent pas satisfaction est une bonne idée, mais il ne faut pas oublier que quelqu’un contraint au départ met en péril une bonne passation des connaissances.
Sur un SI en « sac de nœuds », la perte de connaissances peut être catastrophique.
Certaines solutions ont sans doute été implémentées pour palier des difficultés fonctionnelles. II y a un historique à connaitre, des raisons, des pièges. Les oublier implique souvent de tomber à nouveau dans les mêmes pièges. Il est fallacieux de penser que ces problématiques ont obligatoirement disparu ou que la nouvelle technologie va les anéantir sans effort.
La formation des équipes actuelles peut améliorer les choses mais pas il ne faut pas oublier que sans méthode adéquate et sans conduite du changement, les individus ont tendances à reprendre leurs habitudes (bonnes ou mauvaises) très rapidement.
7 – Externaliser
Faire appel à une société externe qui gère un projet, c’est donner les armes à quelqu’un d’autre sur le champ de bataille.
Certains prestataires sont très bons, d’autres très mauvais. Et dans le second cas, la ré-internalisation des outils risque d’être extrêmement compliquée.
Le code et les documentations rendues, dans le cas d’un échec d’externalisation, ne seront sans doute pas de la même qualité que ceux d’origine.
Et même dans le cas d’une société externe compétente, il faut accorder à celle-ci du temps et un budget suffisant pour adresser la dette technique qu’est l’interdépendance.
8 – Remplacer par un progiciel
Encore faut-il que le progiciel réponde parfaitement aux besoins. Il faudra sans doute adapter le progiciel aux spécificités et au contexte de l’entreprise, et surtout l’intégrer avec les ressources existantes non remplacées.
Cela revient souvent à la même complexité et aux mêmes risques que de réécrire.
Dans le cas d’un progiciel, il est indispensable d’avoir des abstractions / interfaces pour permettre l’intégration avec votre existant.
C’est un choix qui pourra amener plus de stabilité et de souplesse, mais au prix d’un énorme chantier.
Dans le cas précis de l’intégration d’un progiciel, la méthode SOLIDITE permet également de faciliter la transition en contraignant l’utilisation de contrats d’échanges et en imposant des responsables uniques aux différentes ressources du SI.
Aller plus loin sur la maitrise d’un projet
Il n’existe pas de solution miracle universelle. Pour se défaire d’un Système d’Informations devenu un sac de nœuds, il faut agir sur chaque projet méthodiquement.
Il existe de nombreuses méthodes dans des domaines spécifiques. On peut citer YAGNI (You Aint Gonna Need It), KISS (Keep It Stupidly Simple) qui s’appliquent comme des dictons de grand-mère. D’autres comme MoSCoW (Must have this, Should Have this, Could Won’t) pour l’aide en maitrise d’ouvrage. Les 12 principes du Cloud (ou 12 Factors to Cloud Success) mais qui ne s’appliquent qu’à des projets Cloud.
La méthode SOLIDITE est générique. Elle peut s’appliquer aussi bien sur des projets d’applications client lourd que sur des projets de sites web, tant sur des applications et serveurs installés localement que ceux uniquement dans le Cloud. Elle permet de rationaliser des méthodes déjà connues. Surtout, SOLIDITE va à l’essentiel de ce qui est nécessaire pour rompre les dépendances fortes mais aussi pour éviter de les voir revenir.
Un ou une chef de projet ne peut superviser qu’un périmètre réduit au sein d’une organisation. Mais en appliquant SOLIDITE, il ou elle peut reprendre la maitrise de ce périmètre et supprimer les nœuds. Et le contrôle de ce projet va améliorer significativement la pérennité de l’ensemble du Système d’Information.
Le sujet de la suppression des dépendances est vaste et nécessiterait des dizaines d’articles pour rentrer dans les détails et les différents cas d’usage. N’hésitez pas à suggérer en commentaire un point ou un cas client pour lequel vous souhaiteriez de plus amples informations !
Lire les autres articles de cette série sur la méthode SOLIDITE :
