La transformation informatique commence-t-elle vraiment par la technologie ?

PERSPECTIVES #004 — EMATRiX Nova
Entreprise & Informatique

Lorsqu’une entreprise décide de moderniser son environnement informatique, la discussion commence généralement par les technologies disponibles. Quel ERP choisir ? Quel CRM déployer ? Faut-il migrer vers le cloud ? Quels équipements renouveler ? Quelle plateforme collaborative adopter ? Comment intégrer l’intelligence artificielle aux activités de l’entreprise ? Ces questions sont légitimes et devront nécessairement trouver des réponses. Pourtant, les poser trop tôt peut conduire à inverser l’ordre naturel d’une transformation informatique. Une entreprise ne se transforme pas parce qu’elle installe un nouveau logiciel, remplace ses ordinateurs ou déplace certaines applications vers le cloud. Elle se transforme lorsque ces évolutions lui permettent de mieux fonctionner, de mieux exploiter son information, de réduire certaines ruptures opérationnelles, de maîtriser davantage ses activités ou de développer des capacités qu’elle ne possédait pas auparavant.

La technologie est donc un instrument essentiel de transformation, mais elle n’en constitue pas nécessairement le commencement. Avant de demander quel outil doit être adopté, il est souvent plus utile de comprendre précisément ce que l’organisation cherche à améliorer. Cette distinction peut sembler évidente. Elle est pourtant déterminante, car une grande partie de la complexité informatique rencontrée par les entreprises provient précisément de décisions technologiques prises successivement pour répondre à des problèmes particuliers, sans que l’ensemble du fonctionnement de l’organisation ait été suffisamment considéré.

Le réflexe de la solution

Lorsqu’un problème apparaît dans une organisation, la recherche immédiate d’une solution technologique est particulièrement tentante. Si les commerciaux suivent difficilement leurs prospects, un CRM semble nécessaire. Si les documents sont dispersés, une plateforme de gestion documentaire paraît être la réponse. Si les collaborateurs communiquent mal, un nouvel outil de collaboration peut être envisagé. Si la direction manque d’indicateurs, la création d’un tableau de bord semble naturelle. Si certaines tâches consomment trop de temps, l’automatisation ou l’intelligence artificielle apparaissent désormais rapidement dans la discussion.

Chacune de ces réponses peut être pertinente. Le problème apparaît lorsqu’une technologie est choisie avant que les causes du dysfonctionnement aient été correctement comprises. Une équipe commerciale peut disposer d’un excellent CRM et continuer à mal suivre ses prospects si les responsabilités commerciales, les étapes du processus de vente ou les règles de qualification ne sont pas clairement définies. Une plateforme documentaire performante peut devenir aussi désorganisée que les dossiers qu’elle remplace si personne ne sait quels documents doivent y être conservés, selon quelle structure et avec quelles responsabilités. Un tableau de bord peut afficher des dizaines d’indicateurs sans améliorer la qualité des décisions si les données qui l’alimentent sont incomplètes, contradictoires ou mal comprises.

Dans ces situations, la technologie peut fonctionner exactement comme prévu tout en produisant une transformation limitée. Elle a été ajoutée à un fonctionnement existant sans que ce fonctionnement ait nécessairement été remis en question. L’entreprise a alors informatisé un problème au lieu de le résoudre. Cette distinction devient encore plus importante avec l’automatisation. Automatiser une tâche ne signifie pas automatiquement améliorer le processus auquel elle appartient. Une entreprise peut, par exemple, consacrer beaucoup d’efforts à accélérer une opération de saisie alors que la véritable question aurait été de comprendre pourquoi cette information devait être saisie plusieurs fois. Si une seule saisie correctement structurée peut alimenter automatiquement les étapes suivantes, le gain principal ne provient pas de l’accélération de la saisie, mais de la suppression de sa duplication.

La transformation informatique ne consiste donc pas uniquement à rendre les pratiques existantes plus rapides grâce à la technologie. Elle offre également l’occasion de déterminer si ces pratiques doivent continuer à exister sous leur forme actuelle.

Comprendre l’entreprise avant de concevoir son système

Une démarche de transformation gagne ainsi à commencer par l’observation du fonctionnement réel de l’organisation. Comment un prospect devient-il client ? Comment une commande est-elle enregistrée puis exécutée ? Comment les informations passent-elles d’un service à un autre ? Comment un collaborateur retrouve-t-il un document produit plusieurs mois auparavant ? Comment une facture est-elle créée, envoyée puis suivie ? Comment un nouvel employé obtient-il les informations et les accès nécessaires à son activité ? Comment la direction construit-elle une vision suffisamment fiable de ce qui se passe dans l’entreprise ?

Ces questions ne sont pas exclusivement informatiques. Elles concernent d’abord l’organisation. Pourtant, les réponses déterminent directement la manière dont le système informatique devrait être conçu. Il faut notamment comprendre où l’information est créée, où elle est enregistrée, qui la modifie, qui doit ensuite pouvoir la consulter et quel système doit être considéré comme sa source de référence. Il faut identifier les moments où cette information est ressaisie, transformée manuellement, transmise par des canaux informels ou conservée dans des espaces difficilement accessibles. Il faut également identifier les activités qui dépendent excessivement d’une personne, d’un fichier particulier ou d’une connaissance qui n’a jamais été formalisée.

Cette observation révèle souvent que certains problèmes considérés comme technologiques sont en réalité des problèmes d’organisation de l’information. À l’inverse, elle permet également d’identifier des situations dans lesquelles une technologie correctement choisie peut éliminer une rupture structurelle et produire un gain important. La technologie devient alors une réponse à une architecture de besoins clairement comprise, plutôt qu’une solution à laquelle l’entreprise doit ensuite adapter son fonctionnement.

Transformer ne signifie pas nécessairement ajouter

Cette approche conduit également à remettre en question une idée largement répandue : celle selon laquelle la modernisation informatique se traduirait nécessairement par davantage de technologies. Une entreprise peut se transformer profondément tout en réduisant le nombre d’outils qu’elle utilise. Elle peut découvrir que plusieurs applications remplissent des fonctions similaires et qu’une partie d’entre elles peut être supprimée. Elle peut constater qu’un processus complexe existe essentiellement parce que deux systèmes ne communiquent pas entre eux et qu’une intégration permettrait d’éliminer plusieurs opérations manuelles. Elle peut identifier des données collectées depuis des années sans qu’aucune décision ne repose réellement sur elles. Elle peut également découvrir qu’un système déjà déployé possède des fonctions suffisantes pour remplacer une application supplémentaire.

Dans ces situations, la transformation ne résulte pas de l’ajout d’une nouvelle couche technologique. Elle provient de la réduction de la complexité. Cette distinction est importante, car une entreprise peut progressivement devenir prisonnière de son propre environnement informatique. Chaque nouveau besoin entraîne l’ajout d’un nouvel outil, chaque outil possède ses comptes utilisateurs, ses données, ses règles d’administration, ses abonnements et parfois ses propres mécanismes de sécurité. Le coût de cette accumulation n’est pas seulement financier. Il apparaît dans le temps nécessaire à l’administration, dans les difficultés d’intégration, dans la multiplication des accès, dans la dispersion de l’information et dans la dépendance croissante à plusieurs fournisseurs.

La maturité informatique ne devrait donc pas être mesurée par la quantité de technologie visible dans l’organisation. Une architecture relativement simple, correctement intégrée et parfaitement adaptée aux besoins peut être beaucoup plus mature qu’un environnement constitué d’une multitude de solutions sophistiquées mais faiblement coordonnées. La transformation consiste alors à rechercher le niveau de technologie approprié, et non le niveau maximal de technologie disponible.

Les flux d’information révèlent souvent les véritables problèmes

Observer la circulation de l’information constitue l’un des moyens les plus efficaces de comprendre ce qui doit réellement être transformé. Prenons le parcours d’un client. Un prospect découvre l’entreprise, prend contact, exprime un besoin, reçoit une proposition, négocie éventuellement certaines conditions, passe une commande, reçoit un produit ou un service, obtient une facture puis effectue un paiement. Chacune de ces étapes produit de l’information. Dans une organisation correctement structurée, cette information devrait conserver une continuité suffisante pour permettre à chaque acteur autorisé de comprendre la relation sans devoir la reconstruire.

Dans une organisation fragmentée, cette continuité disparaît progressivement. Le formulaire du site contient une première partie de l’information. Le commercial conserve les échanges dans sa messagerie. Une proposition est enregistrée dans un dossier partagé. La comptabilité possède la facture. Le suivi du paiement apparaît dans un autre fichier. Une conversation importante reste dans une messagerie instantanée. La direction reçoit finalement un tableau récapitulatif construit à partir de plusieurs de ces sources. Le problème ne vient pas nécessairement de la qualité individuelle des outils. Il vient de la succession des ruptures entre eux.

Une transformation pertinente cherchera donc moins à remplacer arbitrairement chaque composant qu’à restaurer la continuité du flux d’information. Cela peut nécessiter une intégration, une standardisation, une modification du processus, la suppression d’un outil ou l’adoption d’une nouvelle solution. La réponse technologique dépend du problème identifié, et non l’inverse. Cette logique peut être appliquée à pratiquement toutes les fonctions de l’entreprise : ressources humaines, achats, opérations, gestion documentaire, finance, support client ou pilotage. Dans chaque cas, comprendre comment l’information circule permet de déterminer où se situe réellement la friction.

Les utilisateurs ne sont pas extérieurs au système

Une transformation informatique échoue parfois pour une raison beaucoup plus simple : la technologie choisie n’est pas suffisamment adaptée à ceux qui doivent l’utiliser. Il est tentant de considérer cette situation comme un problème de résistance au changement. Cette résistance existe parfois, mais elle n’explique pas tout. Les utilisateurs peuvent également contourner une solution parce que celle-ci leur impose une complexité excessive, ralentit certaines opérations ou ne correspond pas suffisamment à leurs contraintes quotidiennes.

Lorsqu’une plateforme documentaire est trop difficile à utiliser, les fichiers réapparaissent sur les ordinateurs personnels. Lorsqu’un CRM demande une quantité importante de saisies dont les commerciaux ne perçoivent pas l’utilité, les données cessent progressivement d’être mises à jour. Lorsqu’une procédure de sécurité ajoute trop de friction, certains utilisateurs recherchent des moyens de la contourner. Lorsque plusieurs applications demandent des authentifications et des manipulations différentes pour accomplir une même activité, des procédures informelles apparaissent. Ces comportements constituent des informations importantes sur la qualité du système.

Un système informatique ne se compose pas seulement de logiciels, d’équipements, de données et de réseaux. Il inclut également les personnes qui l’utilisent. L’efficacité de l’ensemble dépend donc de la capacité de l’architecture à intégrer les usages humains. Cela ne signifie pas que le système doit simplement reproduire toutes les habitudes existantes. Certaines habitudes doivent précisément évoluer. Mais cette évolution doit être pensée de manière à ce que les nouveaux processus soient compréhensibles, utilisables et suffisamment cohérents pour être durablement adoptés. L’un des objectifs d’une bonne architecture devrait être de rendre la manière correcte de travailler aussi naturelle que possible.

Mesurer une transformation par les capacités créées

La transformation informatique devient également plus concrète lorsqu’elle est exprimée en termes de capacités plutôt qu’en termes de technologies.

« Déployer un CRM » décrit un projet technologique. « Permettre à l’entreprise de suivre l’intégralité de la relation avec chaque prospect et chaque client » décrit une capacité.

« Migrer vers le cloud » décrit une évolution d’infrastructure. « Permettre aux collaborateurs autorisés d’accéder de manière sécurisée aux ressources nécessaires indépendamment de leur localisation » décrit une capacité.

« Mettre en place un tableau de bord » décrit un outil. « Permettre à la direction d’obtenir une vision fiable de l’activité sans attendre plusieurs consolidations manuelles » décrit une capacité.

Cette différence de formulation change profondément la manière dont un projet peut être évalué.

Si l’objectif est simplement de déployer un logiciel, le projet peut être considéré comme terminé dès que celui-ci fonctionne techniquement. Si l’objectif est de développer une capacité opérationnelle, il faut également vérifier que les utilisateurs l’ont adoptée, que les données sont suffisamment fiables, que les processus ont évolué et que l’entreprise obtient effectivement le résultat recherché. Une transformation informatique réussie devrait donc pouvoir démontrer autre chose que la présence de nouvelles technologies. Elle devrait montrer que l’organisation est désormais capable de faire quelque chose mieux, plus rapidement, plus sûrement ou à une échelle supérieure. C’est cette capacité nouvelle qui constitue la véritable valeur de l’investissement.

L’intelligence artificielle met cette question en évidence

L’essor actuel de l’intelligence artificielle rend cette discipline particulièrement nécessaire. La question « Comment intégrer l’IA dans notre entreprise ? » est désormais posée par un nombre croissant d’organisations. Mais l’intégration de l’intelligence artificielle n’est pas une finalité en elle-même. Elle ne devient pertinente que lorsqu’elle permet d’améliorer une activité clairement identifiée. S’agit-il d’assister la rédaction de documents ? D’améliorer la recherche d’information ? De traiter plus rapidement certaines demandes clients ? D’analyser des volumes importants de données ? D’automatiser certaines tâches répétitives ? D’aider les collaborateurs à prendre des décisions ?

Les réponses déterminent des architectures, des modèles, des données et des niveaux d’intégration très différents. Surtout, l’intelligence artificielle dépend fortement de la qualité de l’environnement informatique dans lequel elle intervient. Une organisation dont les données sont dispersées, dont les documents sont mal structurés, dont les processus sont essentiellement informels et dont les droits d’accès sont peu maîtrisés rencontrera rapidement des limites lorsqu’elle cherchera à intégrer profondément l’IA dans son fonctionnement. L’innovation la plus visible dépend donc souvent de fondations beaucoup moins visibles.

Une entreprise peut expérimenter rapidement des outils d’intelligence artificielle. Mais transformer durablement ses opérations grâce à eux suppose généralement un travail préalable sur ses données, ses processus, son architecture et sa gouvernance. La question de l’IA confirme ainsi un principe plus général : les technologies avancées amplifient la qualité — ou les faiblesses — du système sur lequel elles reposent.

Une transformation peut être progressive

Comprendre l’entreprise avant de choisir la technologie ne signifie pas qu’il faille passer plusieurs années à analyser avant d’agir. La transformation peut être progressive. Une organisation peut commencer par identifier les ruptures qui lui coûtent le plus de temps ou créent le plus de risques. Elle peut ensuite structurer ses identités et ses accès, améliorer l’organisation documentaire, consolider la relation client, intégrer certaines opérations commerciales, renforcer ses sauvegardes ou réduire une dépendance critique.

Chaque étape peut produire une amélioration concrète tout en préparant la suivante. Cette approche est particulièrement adaptée aux PME, dont les ressources sont nécessairement limitées et dont l’organisation peut évoluer rapidement. Plutôt que de chercher à construire immédiatement un système idéal, elles peuvent définir une architecture cible et avancer progressivement vers elle. La différence fondamentale réside dans la cohérence de cette progression. Lorsque chaque investissement est effectué isolément, l’entreprise accumule des solutions. Lorsque chaque investissement constitue une étape vers une architecture comprise et souhaitée, elle construit progressivement un système. La transformation informatique devient alors moins un événement qu’une trajectoire maîtrisée.

La technologie comme conséquence d’une ambition

Dans les trois premiers articles de Perspectives, nous avons défendu l’idée qu’un système informatique ne peut pas être réduit à une collection d’outils, que les conditions d’utilisation de la technologie doivent être prises en compte dès sa conception et que l’informatique devient progressivement une infrastructure stratégique de l’entreprise. Ces trois constats conduisent à une conséquence logique : si le système informatique doit accompagner l’entreprise, il doit être conçu à partir de ce que l’entreprise cherche à devenir.

La transformation ne devrait donc pas commencer par un catalogue de logiciels, une liste de fournisseurs ou la dernière innovation technologique disponible. Elle devrait commencer par une compréhension suffisamment précise des objectifs, des processus, des utilisateurs, des données, des contraintes et des ambitions de l’organisation. La technologie intervient ensuite. Et lorsqu’elle intervient au bon endroit, elle peut produire des effets considérables : éliminer des opérations inutiles, accélérer la circulation de l’information, rendre certaines décisions plus fiables, permettre une meilleure collaboration, renforcer la continuité des opérations, automatiser des tâches répétitives ou rendre possible un changement d’échelle qui aurait été difficile avec les méthodes précédentes.

Chez EMATRiX Nova, nous considérons donc que la transformation informatique ne doit pas être mesurée par la quantité de technologie introduite dans l’entreprise. Elle doit être évaluée par les capacités nouvelles que cette technologie permet de construire. La question initiale change alors de nature. Il ne s’agit plus simplement de demander :

« Quelle technologie devons-nous adopter ? »

Il faut d’abord comprendre :

« Qu’est-ce que notre entreprise doit être capable de mieux faire demain qu’elle ne sait le faire aujourd’hui ? »

Lorsque cette réponse devient claire, les choix technologiques deviennent eux-mêmes plus cohérents. La transformation informatique ne commence donc pas nécessairement par la technologie. Elle commence par l’entreprise. La technologie vient ensuite lui donner les moyens de ses ambitions.

PERSPECTIVES — EMATRiX Nova

Analyses, technologies et transformations de l’entreprise africaine.

Au-delà de la technologie.