Emmanuel Pesenti, Architecte d'entreprise et membre de IT Social, nous interpelle sur le Système d'Information face au Système Informatique, sur le SI face à l'IT, et sur le rôle de l'architecte d'entreprise.
Lors d'une discussion avec une personne de mes connaissances, Project Manager Officer de son état, sur une de nos préoccupations communes du moment, un projet X à quelques 4 milliard d’euros et des brouettes, j'interpelle mon interlocuteur : « Mais que signifie cet acronyme SI ? ». La réponse quasi-automatique fut « Système d’Information, voyons ! ». Et pourtant, les mots employés dans un contexte non technique étaient machines, serveur, protocole, agents intelligents, logiciels embarqués..., allant jusqu’à une esquisse de mise en œuvre. Mais de quoi parle-t-on ? Système Informatique ou Système d’Information ?
Au risque d’enfoncer des portes ouvertes, mes pairs Urbanistes et autres Architectes d’entreprise me pardonneront de me livrer, ici, à un exercice de pédagogie sur notre profession et les moyens, utilisés.
SI vs IT
Nous parlons probablement des deux, mais avec une imprécision flagrante liée au contexte, au projet, et aux limites des postures de chacun. L’Architecte d’entreprise, appelé encore Urbaniste ou Architecte fonctionnel, est au Système d’Information ce que les architectes techniques, les architectes applicatifs, et autre super architectes logiciels, sont au Système Informatique. C’est là une première différence palpable entre les deux systèmes.
L’IT (Système informatique) est l’ensemble des actifs matériels et logiciels de l’entreprise ayant pour vocation à automatiser le traitement de l’information. C’est la partie visible à laquelle tout le monde pense quand on parle de projets et d’infrastructures informatiques. On y inscrit également la R&D, l’innovation technique, et toutes les techniques d’optimisation. Pour résumer, le logiciel, le serveur qui va bien, et les écrans...
Le SI (Système d’information) est l’ensemble des actifs de l’IT (matériels et logiciels, forcement référencé quelque part), qui comprend aussi et surtout les actifs humains et immatériels, les procédés, procédures, et processus, d’industrialisation, sur lesquels on les affecte, les informations de niveau sémantique, organisationnelle et de structure, dites 'Amont'.
À quelle famille d’actif, peut-on associer la flotte de véhicule bleue d’EDF ?
La réponse est très simple, au premier abord, mais mérite d’être nuancée. Elle n’intervient à priori pas dans l’automatisation de tel ou tel service déployé, son usage est manuel, et elle n'interagit à priori qu'avec son chauffeur ; donc on peut facilement comprendre que l’actif en question ne sera pas managé par une direction informatique. Est-ce pour autant un actif du Système d’Information ?
Analysons :
- Existe-t-il un ou plusieurs documents référençant ma camionnette bleue ?
- Ces documents montrent-ils une interaction avec un acteur identifié de l’organisation ?
- Peut-on trouver un premier niveau de formalisme d’un procédé ou mieux d'un processus d’entreprise intégrant ma camionnette bleue et son chauffeur ?
Une réponse négative à ces questions et fin de l’histoire : le véhicule est réduit à un actif comptable à amortir, et c’est sa seule existence dans le SI.
Une réponse positive à ces questions permettrait d’induire que la camionnette est bien une ressource saillante dans le Système d’Information - en plus du système comptable - et contribue, dans une ou plusieurs tâches identifiées, à produire de la valeur.
Et puis...
Puis, au détour d’un autre processus métier, lui parfaitement modélisé, on se rend compte qu’un message entrant fait acte du nom du chauffeur, de la plaque d’immatriculation du véhicule, de la durée d’intervention et du kilométrage. Tiens, la fameuse camionnette bleue serait elle un objet métier, prompt à faciliter la compréhension des processus et de leur interaction et/ou à automatiser un système futur ?
Puis la direction générale, dans un communiqué historique, affirme son intention de réduire les coûts d’intervention en prévoyant mieux les révisions ateliers des véhicules bleus. Là, le faisceau d’information permet clairement de le considérer comme un objet métier, et donc un actif du SI, qui risque de prendre de plus en plus d’importance dans les processus à venir.
10 ans plus tard, le petit véhicule bleu... n’est plus bleu ! Il n’a plus de chauffeur, il est truffé de logiciels dont une partie est stratégiquement développée en interne, et l’autre par un prestataire prestigieux. Il interagit en temps réel avec une base centrale de données, à l’aide d’un protocole non connu 10 ans plus tôt. Sa promotion dans plusieurs processus métiers, a été un facteur concurrentiel de développement déterminant, permettant de rendre l’activité non seulement durable dans le temps, mais rentable. Et oui, l’Architecte d’entreprise est un homo économicus, du développement durable…
- Le suivi et la modélisation du SI a permis, 5 ans auparavant, de faire une fusion-acquisition gagnante avec cette société si brillante dans le développement de logiciels embarqués, comblant le vide fonctionnel que l’Architecte d’entreprise avait détecté suite aux intentions de la DG.
- La DG (qui n’est pas frileuse) avait anticipée cela 10 ans plus tôt avec l’aide de son Architecte d’entreprise.
- Les moyens utilisés pour 'bâtir' sont tout simplement la 'modélisation'. Cette discipline, empruntée à l’ingénierie des systèmes et aux techniques de modélisation 'objet', permet d’allier formalisme et rigueur dans les différentes projections, transformations et dérivations de modèles opérés pour bâtir un ouvrage stable dans le temps. Les procédés et les réflexes de modélisation sémantique, par exemple, sont sensiblement les mêmes que ceux de la modélisation des données : ce sont les objets eux-mêmes qui diffèrent, ainsi que leurs dépendances. Si l’on comprend la différence entre Mathématiques et Physique appliquée, alors par transposition respectivement sur SI et IT, ou sur concepts et data, les différences sont semblables…
Conclusions partielles
- Le SI offre un outil, à moyen et long terme, pour se projeter dans l’avenir en captant la stratégie de l’entreprise, en la projetant et en la décomposant afin de faciliter l’alignement de solutions économiquement viables et durables.
- L’IT est une image fidèle du système informatique opérationnel, actuel, lui-même est une réponse concrète et économique des visions stratégiques précédentes, et dont la responsabilité des managers est de rendre son usage aussi fluide, agile, et utile que possible… La tâche n’est pas simple !
- Le mode projet devrait intervenir sur une vision à maturité du SI de demain, de façon à permettre la transition. Un projet peut donc être considéré comme une transition entre l’IT d’aujourd’hui et l’IT de demain, avec une date de début, une date de fin, et un objectif « SMARTE ».
- Tout actif matériel a vocation à abonder le SI. L’adéquation économique et technique en fera peut être un actif de l’IT dans la vision stratégique, puis concrétisé dans un projet.
- Il est de plus en plus évident que l’adéquation économique anticipée doit prendre immédiatement en compte la composante énergétique comme la future grosse contrainte qui nous attend ; le seul problème dans cette affaire est que tous les dirigeants aujourd’hui naviguent à vue.
Agir consensuellement
Voici donc exposé, sous forme ludique, la différence fondamentale entre une démarche SI et son pendant IT. Les frictions, qui existent parfois entre les deux mondes à vocation plus complémentaire que concurrente, en découlent directement, les uns étant taxé de « philosophes aux théories fumeuses », les autres, de « tekkos aux cheveux long et aux idées courtes ».
Ma position personnel en tant qu’architecte d’entreprise est la suivante : le respect et l’écoute des uns et des autres est une composante fondamentale pour agir consensuellement, chacun à sa place :
- Collègues et amis Architectes, chaque fois que votre interlocuteur, vous dira : « C’est trop technique », il est probable qu’en réalité, il n’ait rien compris à ce que vous lui disiez, et pour garder la tête haute, il botte en touche.
- Collègues et amis MOA, chaque fois que votre interlocuteur, vous dira : « Pourquoi vos besoins ressemblent-ils à des spécifications détaillées ? », c’est que probablement vous ne travaillez pas avec des Architectes d’entreprise, qui challengent ce qu’il y a de meilleur en vous : la vision d’avenir et la compréhension des métiers. Pas la solution !
Je continue de penser que pour être innovant et riche, l’Architecte technique a fondamentalement besoin d’une vision mature et de besoins clairement exprimés, par les urbanistes et les MOA. L’innovation, a besoins de garder son âme d’enfant, car un enfant est détaché des contraintes et des habitudes dont certaines devront être remises à plat. Les Architectes d’entreprise, même si là n’est pas leur vocation, savent aussi écrire une requête SQL optimisée, connaissent la différence entre une variable, statique et d’instance, un pointeur et une référence. Ils savent développer dans leur langage favori, mais ils sont plus utiles encore à faire concrétiser l'expression technique d'une stratégie d'entreprise définie par la Direction Générale".
