Deuxième source

J'ai longtemps lutté contre le centralisme intensif. J'ai toujours été favorable à la liberté, à l'autonomie et à la responsabilité individuelle. Malheureusement, les avantages économiques vont trop souvent à l'encontre d'une organisation distribuée.

Un exemple ridiculement petit, mais révélateur de notre situation : à la cantine, j'ai rencontré un ancien partenaire de tennis qui travaille désormais chez nous au service central d'achat informatique. Il m'a parlé de châssis de disques pour nos serveurs IBM et Fujitsu.

Le cadre accueille des disques SAS/SATA de 2,5 pouces et se compose d'un peu de métal, de beaucoup de plastique et d'un mécanisme de verrouillage.

Chez notre distributeur allemand référencé, une pièce coûte nettement plus de 100 euros. Un fournisseur de San Francisco propose exactement la même pièce pour moins de 20 dollars.

Cette source a été trouvée par un apprenti acheteur sur Amazon.

Ce sont de belles anecdotes, mais cela a déclenché une réflexion chez moi : Nous avons une infrastructure informatique redondante avec plusieurs fournisseurs d'électricité, de serveurs, de stockage et de diesel ; le dernier pour les groupes électrogènes de secours.

La liste de nos fournisseurs secondaires et tiers pourrait facilement remplir un magazine E-3 entier.

La résilience et les plans de secours sont une évidence dans notre architecture informatique globale. Et par nature, ce n'est pas un sujet qui concerne uniquement l'informatique.

La protection de l'usine, la sécurité, les gestionnaires de l'usine et bien d'autres sont ici regroupés dans des équipes de reprise après sinistre. Aucun plan n'est prévu en cas de panne d'une plateforme cloud singulière comme SuccessFactors, Ariba, Concur, HEC ou HCP !

La situation est plus complexe qu'il n'y paraît à première vue : on peut exploiter une architecture de centre de calcul redondante dans le monde entier, qui réagit même en "temps réel". Mais s'il y a un bug dans le logiciel qui conduit l'algorithme à un deadlock, même un matériel à sécurité intégrée n'est plus d'aucune aide.

Naturellement, il existe aussi des solutions à ce problème, mais elles ne peuvent pas être organisées et financées dans un contexte commercial normal : Une tâche est confiée à deux équipes de programmation indépendantes.

La probabilité que les deux équipes développent exactement le même algorithme et y commettent exactement les mêmes erreurs est très faible. Mais même ce double effort ne résout pas tous les problèmes.

En cas d'effondrement d'un algorithme, on peut espérer que l'autre continue à fonctionner - et que l'on est suffisamment protégé. Mais que se passe-t-il si les deux programmes ne se cassent pas, mais donnent des résultats différents ? Il faudrait alors un troisième programme pour déterminer approximativement quel pourrait être le résultat final correct.

Je ne peux malheureusement pas présenter ici de solution pour la communauté SAP et me contenter de rapporter quelques réflexions de nos discussions internes : Au vu des développements techniques actuels et de la faisabilité, la dépendance totale d'un client existant par le biais d'un Software-as-a-Service, comme le représentent HEC, HCP et de nombreuses filiales SAP, ne semble pas justifiable. Une application IoT avec HCP semble réalisable.

Mais que se passe-t-il en cas de K ? Où sont les sauvegardes des données ? Après un téléchargement : Les données peuvent-elles être traitées ? Dans quel format sont-elles alors disponibles ? Quel logiciel est disponible localement et sur site pour pouvoir lire les données ?

Par nature, il y a de bonnes raisons de choisir des solutions cloud comme Business ByDesign et HEC ou S/4 dans le cloud. Ceux qui n'ont pas besoin d'une infrastructure informatique, de peu de ressources et d'une solution immédiate sont probablement bien servis par ces solutions instantanées : Le cloud computing a aussi une raison de vivre !

Mais celui qui est un fidèle client SAP depuis 30 ans, qui a accumulé beaucoup de connaissances et d'expérience et qui peut aussi se prévaloir de l'architecture ERP nécessaire, évitera de s'intéresser aux modèles SaaS. Les clouds hybrides et l'infrastructure hyperconvergée oui, mais le cloud computing avec SuccessFactors, Hybris, Concur, etc. probablement pas.

Ma longue expérience professionnelle me montre que de nombreux problèmes peuvent être résolus sous un autre angle. Nous allons prendre le temps de réfléchir au problème des logiciels de seconde source. Mais de la même manière, notre SAP devrait aussi se donner ou s'accorder un peu plus de temps.

On entend encore des histoires d'horreur sur Hana et les anomalies de l'In-memory Computing. Cela n'étonne pas l'informaticien, car un bon logiciel passe par un processus de maturation.

Jusqu'à aujourd'hui, l'une des plus grandes énigmes de la communauté SAP est de savoir pourquoi on veut pousser Hana sur le marché avec un pied de biche. Repousser l'échéance de 2025 à 2030 et accorder à S/4 Finance et Logistics les revues nécessaires n'est pas un signe de faiblesse, mais de souveraineté et de clairvoyance.

Au moment où j'écris ces lignes, les informations télévisées annoncent que VW ne possède pas non plus de seconde source pour certaines pièces de la Golf.

Jusqu'à présent, je ne pouvais pas imaginer un constructeur automobile sans fournisseur secondaire - apparemment, cela existe. SAP l'a déjà appris à ses dépens : il n'y a pas de deuxième source pour SuccessFactors.