Charles Baudelot, Directeur associé de Feel&Clic
CRM, catalogue électronique, site d’e-commerce, application de workflow, etc… Les projets conçus et déployés seuls par les métiers sont aujourd’hui légions. Que ces derniers s’appuient sur des applications directement accessibles sur le Cloud ou développées par leurs propres prestataires, leurs motivations restent identiques : se tenir à l’écart des équipes, des méthodes et des procédures de la DSI. Leur objectif ? Gagner en réactivité et en liberté fonctionnelle.
Pourtant, avec le recul, il devient évident que cette coupure radicale avec l’informatique présente, à terme, de nombreux inconvénients, voire génère des véritables points de blocage. Au point que de nombreuses directions métiers souhaitent désormais réintégrer à minima leurs applications au sein de la DSI.
Les effets pervers des ilots applicatifs
Avant de se pencher sur les conditions de cette réintégration, arrêtons-nous sur les effets pervers induits par ces ilots applicatifs. Principal écueil constaté sur le terrain : ces projets sont difficilement exportables au reste de l’entreprise en raison de leur incompatibilité avec les standards de la DSI. Lesquels touchent toutes les strates de l’informatique. Prenons le cas des navigateurs, un classique. On ne compte plus les applications web développées par un département compatibles uniquement sur Chrome et Firefox, dans l’impossibilité d’être diffusées aux autres services, Internet Exploreur étant le seul navigateur validé au niveau groupe. Autre cause de friction : la mobilité. Pour ne pas respecter les protocoles de sécurité en vigueur, de nombreuses applications développées pour smartphones ou tablettes n’ont pas accès à certains contenus d’entreprise hébergés sur des serveurs centraux. Enfin DSI et métiers achoppent souvent sur les technologies de développement. Là encore, combien de logiciels développés dans un langage particulier (le PHP par exemple) ne seront jamais maintenus par la DSI qui en a validés d’autres (Microsoft ou java) ?
De telles fractures sont problématiques. Les directions métiers, quoiqu’elles en disent, auront toujours besoin un jour ou l’autre de la DSI pour supporter les applications qu’elles ont choisies ou développées sans la consulter. Ne serait-ce, a minima, que pour généraliser leur production au reste de l’entreprise, et, ensuite, pour en garantir le bon fonctionnement. A un moment ou à un autre, c’est certain, la DSI devra intervenir lorsque les solutions afficheront des signes de faiblesse ou une chute de performance.
Un médiateur pour concilier DSI et métiers
Dès lors, comment rapatrier ces applications dans le giron de la DSI ? Une option - illusoire - consisterait à faire rentrer les utilisateurs dans le rang, en les réalignant sur le mode de fonctionnement historique, c’est-à-dire toutes opérations SI régies par la DSI. Mais soyons réalistes : il est impossible de faire machine arrière. Si les Directions métiers ont gouté à la liberté de déployer en des temps record leurs propres applications, ce n’est pas pour y renoncer aussi vite. D’autant que les projets menés hors de la DSI font office de laboratoire d’expérimentation et sont, en ce sens, précieux pour coller au plus près des usages des utilisateurs.
En revanche, la prise d’indépendance vis-à-vis de la DSI n’interdit pas de respecter un minimum les standards de celle-ci. C’est la voie médiane qui nous semble idéale. Ces contraintes de la DSI ne sont pas si compliquées à mettre en œuvre. Comme indiqué précédemment, elles imposent des choix de développement, de sécurité, d’architectures de déploiement ou de qualité de service.
Seulement, en pratique, le respect de ce socle minimal ne va pas de soi : même minimalistes, ces exigences liées au SI sont trop complexes à décrypter par les métiers. C’est la raison pour laquelle nous préconisons la présence d’un médiateur ; En l’occurrence, d’une cellule intermédiaire. Interne ou externe à l’entreprise, cette structure est constituée de profils techniques et métiers (RH, Marketing, communication, etc.). Elle soutient les projets dès leur genèse ; En amont, donc, de la maitrise d’œuvre traditionnelle.
Dans les faits, cette cellule de démarrage recueille les exigences minimales de l’informatique et les traduit aux concepteurs métiers de l’application. Véritable pôle de vulgarisation, il oriente également les métiers vers les bonnes personnes, au sein de la DSI, capables de de les assister. Enfin, il est investi d’une mission pacificatrice : il doit convaincre les DSI de lâcher du lest. Le développement et le déploiement de certaines applications doivent pouvoir leur échapper à quelques conditions. Plutôt que de contrer ce mouvement d'indépendance, autant l'encadrer. En produisant, par exemple, une charte répertoriant dans un vocabulaire compréhensible par les métiers, les exigences minimales à respecter par toutes les Directions métiers tentées par l'aventure en solo.
Le concept de cette cellule de médiation est nouveau mais ô combien urgent à appliquer dans les entreprises. Au risque de radicaliser encore les positions entre DSI et Directions métiers et de ne plus pouvoir enjamber le fossé qui se creuse chaque jour entre les deux populations…
Pourtant, avec le recul, il devient évident que cette coupure radicale avec l’informatique présente, à terme, de nombreux inconvénients, voire génère des véritables points de blocage. Au point que de nombreuses directions métiers souhaitent désormais réintégrer à minima leurs applications au sein de la DSI.
Les effets pervers des ilots applicatifs
Avant de se pencher sur les conditions de cette réintégration, arrêtons-nous sur les effets pervers induits par ces ilots applicatifs. Principal écueil constaté sur le terrain : ces projets sont difficilement exportables au reste de l’entreprise en raison de leur incompatibilité avec les standards de la DSI. Lesquels touchent toutes les strates de l’informatique. Prenons le cas des navigateurs, un classique. On ne compte plus les applications web développées par un département compatibles uniquement sur Chrome et Firefox, dans l’impossibilité d’être diffusées aux autres services, Internet Exploreur étant le seul navigateur validé au niveau groupe. Autre cause de friction : la mobilité. Pour ne pas respecter les protocoles de sécurité en vigueur, de nombreuses applications développées pour smartphones ou tablettes n’ont pas accès à certains contenus d’entreprise hébergés sur des serveurs centraux. Enfin DSI et métiers achoppent souvent sur les technologies de développement. Là encore, combien de logiciels développés dans un langage particulier (le PHP par exemple) ne seront jamais maintenus par la DSI qui en a validés d’autres (Microsoft ou java) ?
De telles fractures sont problématiques. Les directions métiers, quoiqu’elles en disent, auront toujours besoin un jour ou l’autre de la DSI pour supporter les applications qu’elles ont choisies ou développées sans la consulter. Ne serait-ce, a minima, que pour généraliser leur production au reste de l’entreprise, et, ensuite, pour en garantir le bon fonctionnement. A un moment ou à un autre, c’est certain, la DSI devra intervenir lorsque les solutions afficheront des signes de faiblesse ou une chute de performance.
Un médiateur pour concilier DSI et métiers
Dès lors, comment rapatrier ces applications dans le giron de la DSI ? Une option - illusoire - consisterait à faire rentrer les utilisateurs dans le rang, en les réalignant sur le mode de fonctionnement historique, c’est-à-dire toutes opérations SI régies par la DSI. Mais soyons réalistes : il est impossible de faire machine arrière. Si les Directions métiers ont gouté à la liberté de déployer en des temps record leurs propres applications, ce n’est pas pour y renoncer aussi vite. D’autant que les projets menés hors de la DSI font office de laboratoire d’expérimentation et sont, en ce sens, précieux pour coller au plus près des usages des utilisateurs.
En revanche, la prise d’indépendance vis-à-vis de la DSI n’interdit pas de respecter un minimum les standards de celle-ci. C’est la voie médiane qui nous semble idéale. Ces contraintes de la DSI ne sont pas si compliquées à mettre en œuvre. Comme indiqué précédemment, elles imposent des choix de développement, de sécurité, d’architectures de déploiement ou de qualité de service.
Seulement, en pratique, le respect de ce socle minimal ne va pas de soi : même minimalistes, ces exigences liées au SI sont trop complexes à décrypter par les métiers. C’est la raison pour laquelle nous préconisons la présence d’un médiateur ; En l’occurrence, d’une cellule intermédiaire. Interne ou externe à l’entreprise, cette structure est constituée de profils techniques et métiers (RH, Marketing, communication, etc.). Elle soutient les projets dès leur genèse ; En amont, donc, de la maitrise d’œuvre traditionnelle.
Dans les faits, cette cellule de démarrage recueille les exigences minimales de l’informatique et les traduit aux concepteurs métiers de l’application. Véritable pôle de vulgarisation, il oriente également les métiers vers les bonnes personnes, au sein de la DSI, capables de de les assister. Enfin, il est investi d’une mission pacificatrice : il doit convaincre les DSI de lâcher du lest. Le développement et le déploiement de certaines applications doivent pouvoir leur échapper à quelques conditions. Plutôt que de contrer ce mouvement d'indépendance, autant l'encadrer. En produisant, par exemple, une charte répertoriant dans un vocabulaire compréhensible par les métiers, les exigences minimales à respecter par toutes les Directions métiers tentées par l'aventure en solo.
Le concept de cette cellule de médiation est nouveau mais ô combien urgent à appliquer dans les entreprises. Au risque de radicaliser encore les positions entre DSI et Directions métiers et de ne plus pouvoir enjamber le fossé qui se creuse chaque jour entre les deux populations…
