Le rôle de l'informatique

Joannes Vermorel

Dans de nombreuses grandes entreprises, et probablement la plupart, qui opèrent une supply chain, le département informatique cumule des années de retard. Ce retard est constitué d’une myriade de dysfonctionnements, d’incohérences ou de fragilités qui pourraient être corrigés mais ne le sont pas. En plus de générer d’énormes charges bureaucratiques, cette série sans fin de contrariétés inutiles démotive tout le monde. La supply chain, située au cœur du paysage applicatif, est particulièrement impactée. De façon anecdotique, la partie supply chain¹ représente fréquemment la moitié du retard IT total de l’entreprise.

Ce qui est pire, le retard est fréquemment masqué par une Grand Transition, typiquement une mise à niveau de ERP. Il s’agit de la conséquence directe de l’attente selon laquelle la Grand Transition résoudrait tous les problèmes restés sans solution au cours de la dernière décennie. Pourtant, cette attente est mal placée. En effet, la Grand Transition, même achevée avec succès² une demi-décennie plus tard, aura introduit de nombreux nouveaux problèmes, même si elle parvient à éliminer certains des anciens.

La Grand Transition s’accompagne de deux effets secondaires : premièrement, elle réduit au silence toutes les divisions - sauf IT - en ce qui concerne les questions logicielles ; deuxièmement, elle agit comme un trou noir absorbant tous les budgets et toute l’énergie. Ce deuxième effet est la conséquence du premier.

De par sa nature même, la Grand Transition est extrêmement technique. Personne - à l’exception des spécialistes IT - ne comprend véritablement les subtilités de la migration d’un système de base de données à un autre, ni les incompatibilités subtiles qui existent entre les deux. Une fois que les autres départements sont réduits au silence, il n’y a aucune résistance à canaliser tout vers la Grand Transition. Les autres départements se conforment généralement, animés par l’espoir malavisé que cela accélérera la Grand Transition. Ce ne sera pas le cas. Au contraire : plus le budget est grand, plus l’initiative est lente.

Parmi les grandes entreprises, cette approche a été dominante pendant les deux dernières décennies. Les résultats sont désastreux. Les entreprises paient encore des frais exorbitants pour des applications CRUD³ qui auraient dû être commoditisées – via l’open source – il y a plus d’une décennie. Les retards de mise en œuvre n’ont jamais été aussi longs. Cerise sur le gâteau : les performances et la réactivité des logiciels d’entreprise demeurent aussi médiocres qu’auparavant, alors que le matériel sous-jacent est 1000x plus performant qu’il y a deux décennies.

Cette situation nécessite une correction en profondeur : le département informatique doit cesser d’agir en tant que Grand Architect pour le compte de tous les autres départements. Au lieu de cela, le département informatique doit devenir un coach pour les autres départements, en se concentrant exclusivement sur l’infrastructure⁴, laissant le reste aux départements eux-mêmes avec un état d’esprit facilitateur.

La position de Grand Architect est intenable : même collectivement, l’IT ne peut pas tout savoir sur la finance, le marketing, les ventes, la paie, la production, la comptabilité, le transport, la planification, la conformité, le juridique, etc. Le touche-à-tout rate la plupart des initiatives qu’il entreprend. Chaque livraison à moitié aboutie génère davantage de problèmes à corriger par la suite. La création de retard est à la fois inévitable et sans fin. À mesure que les logiciels deviennent plus omniprésents année après année, le retard devient de plus en plus ingérable.

La solution est simple⁵ : abandonner le concept de Grand Architect et repositionner le département informatique en tant que facilitateur et mentor pour toutes les initiatives liées aux logiciels exécutées par les autres départements. Confier aux départements, comme la supply chain, la responsabilité de leurs propres initiatives logicielles les force à revoir leurs propres ambitions : plus de boucs émissaires pour justifier un retard incontrôlé. Le département assume à la fois ses succès et ses échecs.

Cependant, la solution est presque jamais mise en œuvre.

Repositionner l’IT en tant que facilitateur signifierait réduire ses budgets de moitié ou plus, conséquence directe d’une empreinte opérationnelle nettement réduite au sein de l’entreprise. Cela est inacceptable pour le responsable du département IT dont le poste rivalise souvent, en termes de pouvoir, avec celui du PDG lors de la Grand Transition.

Cela signifierait également que les responsables de département devraient être tenus responsables de leurs propres initiatives logicielles - ou de leur absence. Il est rassurant de pouvoir renvoyer la faute sur l’IT chaque fois qu’un projet déraille - ce qui est fréquent dans le domaine des logiciels. Cela permet aussi aux départements d’éviter la question épineuse du recrutement de talents IT, qui est un défi depuis des décennies.

Néanmoins, à mesure que les logiciels d’entreprise évoluent vers le SaaS (Software as a Service), la perspective du Grand Architect s’estompe peu à peu pour devenir sans importance, les fournisseurs prenant en charge l’hébergement, les sauvegardes, les mises à jour, etc. Ainsi, bien que de manière incidente, les responsables de département sont progressivement contraints de devenir responsables de leurs décisions logicielles, et le département IT est progressivement forcé de renoncer à ses anciennes responsabilités.

Les logiciels d’entreprise sont arrivés avec un retard d’une décennie à la fête du SaaS. Je prédis qu’il faudra une autre décennie pour que la plupart des grandes entreprises abandonnent l’état d’esprit du Grand Architect.