Construire un système d’informations qui survivra à la numérisation de l’économie.
Ces derniers temps, il m’arrive souvent de déjeuner avec des gens travaillant dans des entreprises industrielles et invariablement nous en arrivons toujours à une discussion sur la numérisation du monde.
Je pense qu’il y a à l’heure actuelle une grande inquiétude de la part de pas mal d’acteurs dans ce monde concernant la numérisation. Je pense qu’à présent tout le monde a compris que personne n’est à l’abri de se faire méchamment bousculer dans son domaine par le numérique.
De la peur de Google, à la construction de compétences internes.
Pendant le Hacking Industry Camp, nous avons d’ailleurs eu une présentation de l’industrie 4.0 par Jean-Daniel Weisz où il a expliqué que le moteur de ce phénomène de transformation est justement la crainte des grandes entreprises industrielles allemandes de se faire marginaliser par des géants tels que Google.
Ce constat est sans appel ; on est loin du déni de l’industrie du disque à l’époque de l’émergence de Napster. Mais au delà du simple constat, la question pour l’entreprise est : “qu’est ce qu’on fait maintenant ?”.
Ma conviction est qu’à terme le software sera une compétence clé de l’entreprise qui aura réussi sa numérisation. Mais il est certain que, du jour au lendemain, les entreprises ne vont pas se mettre à construire un service en interne pour s’occuper de développer leurs propres logiciels. On peut néanmoins poser les premières briques d’un système d’information performant et évolutif.
Les débuts de l’informatisation.
Jusqu’à présent, la majorité des entreprises industrielles ont investi de l’argent pour s’informatiser. C’est à dire optimiser des processus existant grâce à l’outil informatique. Ainsi la gestion de stock ne se fait plus sur un cahier mais sur un logiciel qui compile en principe pas mal de fonctionnalités afin de suivre l’ensemble des activités de l’entreprise.
On a ainsi déployé dans les entreprises des progiciels volumineux, des ERP (Enterprise Resource Planning) qui assuraient la supervision de l’ensemble des processus de l’entreprise. Souvent ces intégrations ont été délicates ; ces progiciels cherchant à tout faire étaient onéreux et demandaient à l’entreprise d’adapter ses processus à la façon de voir de l’applicatif.
Il existe ainsi pas mal d’histoires horribles de gens dont le passage à un ERP a duré des années avec des coûts faramineux d’implémentation largement sous-estimés au départ. Cela a entraîné une méfiance naturelle des entreprises vis-à-vis de ces grands programmes monolithiques qui fonctionnent souvent en mode “tout ou rien”. Du coup, des solutions alternatives sont apparues, en opérant souvent sur un périmètre plus restreint, pour un coût bien inférieur.
C’est ainsi que le terme ERP est désormais associé à énormément de solutions, tous les éditeurs se sont lancés dans la danse, certains gros éditeurs tels que Microsoft rachetant des solutions existantes pour construire une offre pertinente rapidement.
Les défauts d’interopérabilité.
Mais il y a toujours un problème fondamental : quel que soit le périmètre pris en charge par votre ERP, vous arriverez toujours à un moment où vous voudrez faire quelque chose qui n’est pas pris en charge de base, le “truc pas prévu à la base”. Un exemple ? Un jour votre magasinier vous explique qu’il a découvert les tags RFID et que cela serait vraiment super pour suivre le stock de consommables de l’entreprise. Il a trouvé une solution qui gère cela, mais c’est une application à part et visiblement elle ne peut pas communiquer avec votre ERP, ce qui serait quand même sympa pour lancer l’approvisionnement automatique des consommables en question.
Et c’est là qu’apparaissent les maux de têtes parce que finalement le grand défi à l’heure actuelle, c’est l’interopérabilité des solutions. Pour apporter des réponses à ce problème, repartons simplement en arrière et voyons ce qu’est un système d’informations.
Retour aux bases.
Dans sa forme élémentaire, un système d’information n’est finalement qu’un ensemble de données et de traitements associés. Si on prend l’exemple de votre ERP, il stocke l’ensemble des données pertinentes (comptabilité, stocks, etc.) et vous permet d’interagir avec par le biais d’une interface utilisateur. Cette interface utilisateur ne vous laisse pas faire ce que vous voulez. Toutes vos demandes sont filtrées à travers des règles métiers afin d’assurer la cohésion des données et de gérer les droits d’accès de chacun.
Ce qui nous amène à la première façon de faire de l’interopérabilité entre des logiciels : avoir un être humain qui s’amuse à ressaisir les informations à la main. Cela parait stupide de prime abord, mais finalement si vous regardez, c’est déjà ce que fait votre entreprise. Imaginons par exemple que vous recevez encore des commandes par fax, vous n’avez pas de traitement automatisé pour vous occuper de cela, vous avez donc quelqu’un qui va saisir les informations de la commande sur votre ERP.
Il est évident que cette méthode a des limites : si le fax revient à la mode, je vous laisse imaginer l’armée de gens qu’il vous faudra pour traiter toutes les commandes. C’est pourquoi fort de ce constat, on a inventé le dialogue “machine to machine”. Comme son nom l’indique, il s’agit de permettre à deux systèmes d’informations de dialoguer directement l’un avec l’autre sans l’intermédiaire d’un être humain.
L’idée n’est pas nouvelle, depuis le début de l’informatique et la télématique on a pu voir de tels exemples de machines qui communiquent entre elles. Mais il s’agissait souvent d’intégrations faites sur mesure avec des protocoles fermés. En gros, soit les logiciels que vous essayez de connecter étaient prévus pour, soit c’était sans espoir. Cette incompatibilité n’était pas que le fruit d’une non standardisation, elle était souvent la conclusion logique d’une stratégie de client captif. En gros, tout le monde choisissait son format de prise électrique et utilisait un voltage différent des autres.
Cette stratégie a perduré pendant des années et fait les choux gras de certains fabricants. Quelques acteurs avaient essayé en vain d’imposer des standards, plus ou moins lourds, plus ou moins liés à une technologie mais sans succès. Sans succès jusqu’à l’émergence d’un nouvel acteur : le web.
Le web, un standard naturel.
Si dans les premiers jours du web, il s’agissait simplement de distribuer des documents construits sur un serveur distant, rapidement on a vu apparaître les premières applications web, c’est à dire des applications qui fonctionnent dans votre navigateur web. Ces applications avaient la particularité de mettre en oeuvre des technologies web standard, principalement HTTP et des API REST. Derrière ces noms barbares, il s’agit juste d’utiliser un même format de prise électrique et le même voltage.
Ces dernières années, de nombreuses applications sont à présent utilisées en mode SaaS (Software as a Service) c’est à dire en location au mois, exécuté dans un navigateur web. Rapidement ces applications ont commencé à pouvoir s’interfacer les unes avec les autres simplement en proposant une API. Qu’est ce qu’une API ? C’est simplement un ensemble de fonctionnalité qui permet à une autre application d’interagir avec l’application qui propose l’API. En gros, on peut utiliser les fonctionnalités d’une application à distance, à travers l’internet, et donc faire facilement un dialogue “machine to machine”.
Illustrons cela par un exemple simple : si j’ai un logiciel de comptabilité, et j’aimerai peupler des champs sur un client de type nom, adresse, nom du gérant, etc. Je peux soit demander à mon utilisateur de taper ces renseignements à la main soit simplement lui demander le SIREN de l’entreprise et utiliser une API externe qui va me donner les informations. Par exemple, le résultat pour mon entreprise est celui ci. Vous pouvez alors vous amuser à changer dans votre barre d’adresse la requête. Le dernier chiffre est mon numéro SIREN ; si vous en avez un, remplacez le puis appuyez sur entrée et vous verrez les informations sur votre entreprise.
L’exemple est simple mais il permet de comprendre la “plomberie” sous-jacente des applications. Maintenant que pourrions nous faire avec cela ? Et bien prenons un exemple, celui d’une entreprise qui ferait des profilés aluminium sur mesure.
L’entreprise vu comme un système d’information.
D’ordinaire les clients appellent l’entreprise pour demander si on peut réaliser son profilé, envoie un plan par coursier ou par mail et derrière on va lui dire si son profilé et réalisable par l’entreprise et si oui, dans quel délai et pour quel prix en fonction de la quantité souhaitée.
Maintenant, on peut aussi voir cette entreprise comme un système d’information qui fournit une API permettant à l’extérieur d’interroger les capacités de production de l’entreprise. Dans notre exemple précédent, imaginons le bureau d’étude qui utilise un logiciel 3D, le dessinateur réalise son profilé, puis demande une “quotation”. Automatiquement le logiciel va se connecter à l’API de l’entreprise, envoyer le plan et les autres informations telles que la quantité souhaitée. Le logiciel de l’entreprise va alors analyser le plan pour voir s’il est réalisable, puis avec des règles métiers propres à l’entreprise va dire s’il s’agit d’un plan valide et si c’est le cas faire une “quotation” à la volée et la retourner au logiciel.
Le dessinateur aura donc en quelques secondes une validation de ce qu’il fait et une offre pour réaliser sa pièce qu’il pourra de suite valider ou non afin qu’elle soit lancée dans le prochain cycle de production.
On imagine alors facilement les prochaines itérations ; la possibilité par exemple pour une entreprise de savoir en un clic qui est capable de réaliser sa production et à quel tarif. Il est aisé alors de voir les gains de productivité dans une telle solution, d’un côté comme de l’autre, mais aussi la possibilité d’exclure des marchés les entreprises qui ne seront pas à niveau.
Ce scénario n’est pas très éloigné de la réalité, il est en train de se mettre en place et existe même déjà dans certaines industries. Ainsi si l’on prend la publicité sur internet, il s’agit de plus en plus de systèmes automatisés agissant comme des bourses mettant en relation une offre et une demande en temps réel.
Par exemple, un utilisateur se connecte, son profil est envoyé en mode “nous avons cet utilisateur qui veut acheter l’espace publicitaire qu’il va voir”. Les différentes entreprises répondent instantanément en faisant des offres par rapport à la pertinence de cet utilisateur pour leur campagne. Tout cela se fait sans l’intervention d’un être humain, ce dernier ayant paramétré sa campagne en amont (“combien je suis prêt à mettre sur quel profil”).
Il est aisé de comprendre que cela va se développer. Et donc, s’il y a un conseil à donner, c’est pour le dirigeant d’entreprise de s’assurer que chaque brique logicielle déployée au sein de son entreprise peut être pilotable par le biais d’une API. Dans un premier temps cela permettra une meilleure interconnexion des outils de l’entreprise et surtout cela ouvrira la porte de la collaboration avec le reste du monde.
