Architecture SI : 10 commandements pour les DSI

Bien que les enjeux soient globalement les mêmes depuis l’apparition des SILe SI désigne le système d'informations d'une organisation., la complexification des technologies, l’agrandissement de la surface de travail et la multiplication des interlocuteurs ont rendu le rôle de DSILa DSI est la direction des systèmes d'informations d'une organisation. de plus en plus complexe. Et comme il est parfois difficile d’y voir clair, on va prendre un peu de recul pour vous donner les 10 commandements pour optimiser l’architecture de votre SI !

Commandement #1 - Les données doivent être à un seul endroit

Bien que ce conseil semble relever du bon sens, ce n’est pas pour rien que nous avons choisi de le mettre en première position. En effet, selon nous, le stockage des données est l’un des points les plus importants concernant l’architecture de votre SI. ll n’existe pas de pire situation que de devoir croiser des données de différents logiciels pour avoir la complétude des données.

Concrètement, un bon SI possède des référentiels de données, et chaque référentiel de données est administré à un seul et unique endroit. Faites la liste de toutes les entités importantes dans le contexte de votre entreprise : les clients, les factures, les produits, les commandes… Peu importe que ce soit le CRM, l’ERP, un microservice dédié, ou l’eShop, chaque entité doit avoir un seul point de vérité au sein du SI.

Vous avez d’ailleurs peut-être déjà entendu parler du MDM (master data management), une approche qui centralise tout dans un seul fichier maître. Au final, quelle que soit la solution que vous choisissiez, le mot d’ordre reste le même : simplifier !

Commandement #2 -À tes moyens tu t’adapteras

Contrairement à ce que l’on pourrait penser, voir toujours plus grand n’est pas forcément synonyme de réussite, en tout cas, pas en ce qui concerne votre système d’informations et son architecture SI ! Penser trop grand est un biais très commun, problème amplifié ces dernières années par la complexification des technologies et la large diffusion des architectures SI appliquées par les grands groupes. Mais tout le monde n’a pas les moyens et les besoins d’avoir l’intégralité des technologies du marché, et ce n’est pas un problème. N’oubliez pas : pour chaque brique, chaque technologie et chaque logiciel que vous rajoutez, il faut quelqu’un qui la maîtrise !

Il faut avant tout savoir penser à long terme. Alourdir son SI avec des choses qui n’auront plus d’utilité dans quelques mois, c’est se tirer une balle dans le pied. Par exemple, on vous conseille de bien réfléchir si vous souhaitez intégrer de l’IA dans votre SI !

Prenons un cas d’application concret : AWS propose des architectures très complexes qui coûtent très chères, souvent peu pertinentes pour les clients. Faîtes attention au risque d’avoir une surprise sur votre facture.

En bref, on ne copie pas son voisin, et on opte pour du sur-mesure en fonction de ses besoins !

Commandement #3 - Optimiser l’architecture SI avec un minimum de technologies de développement

Si vous écoutez notre podcast, vous savez déjà qu’en tant que développeur, on vous conseille de connaître le plus de langages possible. Mais pour votre SI, c’est tout le contraire !

Accumuler les stacks technologiques est le meilleur moyen de ralentir le développement. On ne peut que vous conseiller de limiter au maximum le nombre de langages et de frameworks. Choisir une stack et s’y tenir permet une plus grande flexibilité. En effet, vous pourrez plus facilement former vos équipes et vous gagnerez en agilité.

Aussi, on ne vous conseille pas de tout miser sur le nouveau framework à la mode. Bien que l’idée puisse être attrayante, il vaut mieux attendre une certaine maturité de la techno.

Rappelez-vous que ce n’est pas la stack technologique qui fait qu’un projet rate, c’est l’encadrement, le métier et les développeurs !

Commandement #4 - Supprimer plutôt que de rajouter

Souvent, on cherche à combler un besoin par l’ajout d’une nouvelle technologie ou d’un logiciel. Mais généralement, la bonne approche est de commencer par en supprimer ! Concrètement : si plusieurs choses ont la même utilité, c’est qu’il y a un problème.

Un conseil : n’hésitez pas à acter ça en début de projet. Il faudra forcément appuyer sur le bouton “supprimer” à un moment ou un autre, et c’est tout-à-fait normal ! Si vous voulez garder la main sur votre SI et ne pas vous y noyer, il faut en enlever. Si vous en accumulez trop sur le long terme, vous prenez le risque de devoir tout jeter.

Commandement #5 - Le document n’est pas un processus

On ne le rappellera jamais assez : le document n’est pas le support d’un processus ! Digitaliser son SI en partant des documents n’a pas de sens. Il faut plutôt penser son SI comme un échange de données entre des systèmes et non comme un support. Le papier n’est là que pour figer un process à un moment donné.

En informatique, le document est difficile à gérer : il est volumineux, compliqué à générer, à déplacer et à mettre à jour. Alors n’en abusez pas !

Commandement #6 - Les outils techniques ne doivent pas être utilisés par les utilisateurs finaux

La GED, les référentiels, les outils d’envoi d’email, de signature électronique… Autant de briques utiles au SI mais qui ne devraient en aucun cas être utilisées par les utilisateurs finaux ! C’est au sein de leur outil métier que ces fonctionnalités doivent être intégrées. Il faut rendre le quotidien des utilisateurs le plus simple possible et arrêter de les faire jongler avec des briques technologiques.

Commandement #7 - Par population métier, un seul outil tu garderas

Quoi de pire que de jongler entre différents outils pour réaliser un processus métier ?

L’idée est de construire des portails applicatifs qui vont utiliser toutes les briques techniques du SI et qui vont permettre de réaliser le processus en question. Normalement, dans un SI du 21e siècle, toutes les autres briques du SI ont des API que vous pouvez appeler, ce qui vous permet donc de construire assez facilement des portails métiers pour chaque grande population de votre entreprise !

Commandement #8 - L’extranet, l’espace client en dernier !

Souvent, on a envie de commencer le processus de digitalisation d’une entreprise par ce que le client voit, c’est-à-dire le bout du SI : l’extranet, l’application mobile… Malheureusement, pour offrir des fonctionnalités au client par l’intermédiaire de ces canaux, il faut que tout soit prêt en amont. Commencez donc plutôt par structurer votre SI, et on vous promet que le projet espace client sera un jeu d’enfant ! Attention, ça ne veut pas dire que vous ne pouvez pas y penser en amont, seulement que vous devrez le développer en dernier.

Si vous développez l’extranet en premier, vous allez développer une V1. Une fois qu’il sera branché au reste du SI, il est fort probable qu’il faille changer beaucoup de choses.

Commandement #9 - Le moins de spécifique possible dans les progiciels

Dans certains cas, il peut être pertinent de couvrir un des pans de votre SI avec un logiciel du marché. Mais si vous optez pour cette solution, on vous conseille de faire le moins de spécifique possible dedans, et ceci pour plusieurs raisons :

• Les consultants progiciels, moins nombreux, coûtent beaucoup plus cher que les consultants classiques, et vous risquez rapidement de voir la facture gonfler.
• Le spécifique sera un frein pour les mises à jour de l’éditeur. Vous allez devoir, à chaque montée de version, réadapter votre spécifique et ce, avec un rythme qui n’est pas celui dont vous décidez, mais celui de l’éditeur.
• Les performances du développement spécifique dans un progiciel sont souvent moyennes… Et oui, l’outil est pensé d’une manière et sûrement pas de la manière à optimiser vos processus à vous !
• Et dernière règle, si vous achetez un progiciel, c’est parce que celui-ci doit couvrir vos processus métier. Si ce n’est pas le cas, alors changez de logiciel ou adaptez votre entreprise pour rentrer dans les cases du progiciel !

Commandement #10 - Maitriser la connaissance

Il n’est pas rare de voir des DSI alterner des phases d’externalisation et d’internalisation sans arriver à trouver un équilibre. Essayer de retrouver la connaissance que l’on a laissé partir, c’est une perte de temps considérable.

Le fond du problème n’est pas tant la connaissance en elle-même, c’est la connaissance métier ! Car, dans le développement, même si on opte pour l’externalisation, ce qui est important, c’est de continuer à savoir ce que l’on veut faire, et continuer à comprendre, informatiquement parlant, comment fonctionne le tout.

Il est également important de ne pas laisser l’entièreté de la connaissance entre les mains d’une seule et unique personne. Dans un contexte ou les employés changent de poste de plus en plus souvent, il est risqué de mettre tous ses oeufs dans le même panier. En effet, un employé qui compte quitter l’entreprise dans les semaines à venir ne sera probablement pas le plus collaboratif quant à la transmission de sa connaissance ! De plus, la mémoire humaine est faillible, et il est très probable qu’une partie de la connaissance soit oubliée. Pour réduire les risques, on vous conseille de ne pas attendre le dernier moment pour documenter la connaissance.

Si la gestion de la connaissance dans les projets IT vous intéresse, n’hésitez pas à consulter notre article sur le sujet !

Optimiser l’architecture de son SI : un défi long terme !

Forts de nos aventures chez nos clients depuis quelques années, on a essayé de vous condenser notre pensée en 10 commandements ! Bien sûr, ils ne seront pas forcément applicables à chaque contexte, mais on espère que ça vous aidera tout de même pour optimiser l’architecture de votre SI !

Pour aller plus loin sur le sujet, vous pouvez écouter l'épisode de notre podcast associé. On vous souhaite bon courage pour vos travaux d’optimisation :)