Nous menons de nombreuses missions avec des architectes SI comme Jean-Paul Figer (lien vers son blog). Ce qui est remarquable quand nous travaillons avec lui, c’est qu’il trouve toujours des solutions à tout et en utilisant à chaque fois les bonnes technologies. Cette capacité nous permet notamment de réussir des projets complexes en s’appuyant sur une architecture SI moderne, peu couteuse, scalable. Nous allons vous présenter aujourd’hui les principes et les règles que nous suivons.
Je m’appuierai sur le travail de Jean-Paul sur cet article.
Une bonne architecture SI doit s’appuyer sur Internet
En 2021, il y avait 5,3 milliards d’utilisateurs de téléphones portables dans le monde. Le principal besoin a changé, ce n’est plus téléphoner, c’est l’utilisation d’Internet. Je nous vous parle même pas des ordinateurs qui sont de plus en plus performants et moins chers. Et je ne vous parle pas non plus de la révolution numérique avec la data, l’Iot, les moteurs de recherche, les SaaS, l’IA…
Il est maintenant à la portée de toute personne de créer des infrastructures numériques relativement simplement grâce aux infrastructures Internet et au Cloud computing.
Grâce à tous ces progrès et à Internet, la vie des utilisateurs est simplifiée, de nombreuses tâches sont dématérialisées ou automatisées, et le meilleur est encore à venir.
Internet n’est donc pas prêt de disparaître et sera l’architecture SI principale des 15 prochaines années. Vous l’aurez compris la première recommandation d’architecture SI est d’utiliser l’architecture, les normes et les composants d’Internet comme éléments constitutifs des systèmes informatiques d’entreprise. C’est la garantie de faire les bons choix pour les 5 à 10 prochaines années au moins.
Les principes fondamentaux d’une bonne architecture SI selon Jean-Paul Figer
Simplicité et économie
Entre deux solutions répondant aux besoins, choisir la moins coûteuse parmi les solutions les plus simples.
En effet, plus c’est simple à mettre en oeuvre mieux c’est ! Attention, il faut bien prendre en compte la simplicité de maintenance et d’exploitation lorsque que vous cadrez un projet.
Et moins c’est cher mieux c’est ! Attention, il ne faut pas uniquement chiffrer le coût en équipement, logiciel et prestation externe, il faut également chiffrer le coût du temps que passe vos équipes sur le projet puis sur la maintenance, les évolutions d’un produit et l’exploitation.
Abstractions au bon niveau
Il ne faut pas réinventer l’existant ! Lorsque vous menez un projet ou construisez une cible, utilisez des protocoles existants pour garantir la stabilité et la durabilité de votre produit.
Séparation claire des préoccupations
Il faut que chacun joue son rôle ! Ce n’est pas aux utilisateurs métiers de proposer des solutions, c’est aux architectes ! De la même manière ce n’est pas à un chef de projet de décider d’une solution, il doit en tester plusieurs qui correspondent aux besoins avec les utilisateurs puis c’est aux utilisateurs de décider !
Par exemple pour concevoir un projet :
- Le métier définit son processus et son besoin indépendamment des technologies
- Les chefs de projets les formalisent et les communiquent aux architectes
- Les architectes proposent des solutions
- Les chefs de projets testent les solutions avec les utilisateurs et communiquent aux métiers ce qui est dans et hors périmètre
- Les métiers choisissent la solution la mieux adaptée
Répartition équilibrée des responsabilités
Il faut uniquement réserver à l’échelon supérieur ce que l’échelon inférieur ne pourrait effectuer que de manière moins efficace. Par exemple, un manager ne doit pas donner une tâche qu’il maîtrise à un de ses n-1 qui ne le maîtrise pas sans accompagner/former la personne en amont. Dans le cas contraire, cela créera de l’instabilité dans le projet.
Les règles d’architecture SI pour réussir vos projets et stratégie SI
- Pour réduire les risques, faites du prototypage avant de faire des choix. Deux types de prototypes sont possibles : POC et MVP
- Construire en parallèle de l’existant. N’essayez pas d’utiliser ou de vous connecter directement aux systèmes existants tels quels. Il faut créer des interfaces/passerelles pour ne pas perdre de temps et d’argent sur les anciens systèmes, souvent obsolètes
- Ne pas faire du neuf avec du vieux, c’est à dire ne pas investir du temps et de l’argent en faisant des tests sur des systèmes ne respectant pas les principes d’architecture SI lorsque l’on peut tester d’autres solutions. Une architecture obsolète peut limiter l’expérience utilisateur et biaiser les résultats d’un test
- Préférer les solutions SI ayant une activation sans besoin de paramétrage inital
- Automatiser les administrations des solutions SI
- S’assurer auprès des fournisseurs que leurs applications sont belles et bien des solutions en Cloud Computing et non des solutions en hébergement. Il n’est pas rare de croiser des éditeurs de logiciel qui vous assurent que leur application est en mode SaaS alors qu’ils hébergent eux même chez eux les outils ou qu’ils ne mutualisent pas les ressources techniques. Nous ferons prochainement un article sur ce sujet.
- Il faut mettre en place une sécurité de bout en bout
- Tous les utilisateurs sont authentifiés par un SSO (Clés SSH pour les exploitants)
- Tous les services sont authentifiés (Certificats) et les échanges sont chiffrés
- Toutes les transactions sont autorisées (Zero Trust, RBAC)
- Lorsque vous voulez mettre en place une stratégie SI ou une application SI. Il faut toujours les diviser en projets « courts », idéalement 3 mois. En effet, cela permet de mieux faire les choses, de mieux travailler avec les métiers et de montrer des résultats tangibles tous les 3 mois.
