Dans un mode projet traditionnel, la généralisation des processus de gestion de la vie des systèmes d’information, l’industrialisation des SI, la virtualisation et la mise en place de solutions de sécurisation standardisées devraient permettre un déploiement simple et rapide des applications. Ce n’est malheureusement pas toujours le cas.
Un constat pour le moins mitigé
Malgré les évolutions technologiques, il reste toujours difficile d’insérer correctement une application métier dans le système d’information d’une entreprise. Cela est en partie dû au fait que les métiers souhaitent souvent aller au-delà de leur attribution en ne s’intéressant pas uniquement au « Quoi ? » mais aussi au « Comment ? ». Cet état de fait provient d’une sorte de « syndrome du métier roi », qui peut conduire à des extrêmes comme la mise en service d’applications sans que la DSI soit prévenue (le shadow IT). Cela peut notamment être le cas lorsque les règles et processus ne sont pas jugés pertinents ou trop lents par le métier.
En conséquence, de nombreuses spécificités apparaissent et ne sont pas toujours résorbées : non-respect des normes internes et réglementaires, non-utilisation des infrastructures et offres de services présentes, perpétuelle « réinvention de la roue » …
Ce phénomène implique des pertes de temps et des surcouts qui pourraient être évités. Il implique aussi des risques pour le bon fonctionnement et la sécurité du SI car la maitrise des applications est moindre.
Tout d’abord, cadrer
La mise en place d’un cadre clair et cohérent décrivant le SI est un prérequis fort de la bonne intégration des applications métiers dans le SI. Il doit être conçu pour s’appliquer également aux applications métiers basées sur des composants physiques industriels.
Ce cadre s’appuie sur la rédaction de politiques, que ce soit pour les infrastructures (positionnement des applications, gestion de la disponibilité, piles systèmes et logicielles préconisées …), pour le réseau (règles de raccordement, gestion du dimensionnement des échanges …) ou pour la sécurité (gestion de la confidentialité et de l’intégrité des données, gestion des authentifications et habilitations …), avec en particulier l’analyse des risques associés aux données et à leurs traitements. L’inclusion du cadre réglementaire et légal (réglementations informatiques et libertés, loi de programmation militaire …) est nécessaire.
De même, toutes les infrastructures et les services qu’elles rendent doivent être présentées sous forme d’offres de services, incluant les contraintes d’acceptation et dès que possible, les couts et délais associés à leurs utilisations, d’autant plus si le système s’oriente vers une approche micro-services et repose sur des API.
Tous ces éléments doivent être intégrés dans le schéma d’urbanisme du SI.
Une fois défini, le cadre est à dériver sous forme de toolkits permettant aux métiers d’identifier rapidement leurs besoins, afin d’intégrer les contraintes associées dans leurs pré-études et leurs appels d’offres.
Puis, fonctionner en mode processus
Le cadre mis en place doit s’accompagner d’un ensemble de processus facilitant la conception et la mise en place des applications métiers.
Les processus accompagnant la conception applicative sont, de loin, les plus importants, puisqu’ils amènent aux architectures applicatives à déployer. Ils doivent intégrer, dès les premières phases, l’exploitant ainsi que les équipes gérant le réseau et la sécurité du SI, qui sont amenés à faire partie de l’instance de validation des architectures applicatives.
Dans un cycle projet traditionnel, il est préférable de découper l’étude et la validation de l’architecture des applications en deux parties.
La première partie, doit traiter l’architecture fonctionnelle uniquement. Celle-ci commence par la fourniture des besoins par le métier : population cible, données utilisées et traitements associés. Une étude de ces besoins vis-à-vis du cadre défini permet alors de déterminer les contraintes imposées à l’architecture et les offres de services pouvant répondre au besoin métier. Cette étude passée, l’architecture fonctionnelle peut être définie par le métier et validée par l’instance de validation des architectures applicatives.
La seconde partie, qui s’intéresse à l’architecture technique, favorise l’utilisation des offres identifiées précédemment. L’architecture proposée peut enfin être validée en impliquant dans cette décision les responsables des offres de services retenues.
Et le plus important… faire appliquer !
La mise en application du cadre et des processus associés est à faire étape par étape.
Il convient, en premier lieu, d’identifier au moins un correspondant métier au sein de la DSI moteur et connaisseur de l’organisation, afin de tester et de rôder le cadre et les processus. Une fois ce premier test effectué, il peut être étendu au sein de la DSI, en commençant sur une base de volontariat, et ce, avec l’appui du DSI.
La dernière phase, l’extension du processus à l’ensemble des métiers, est plus complexe en ceci qu’elle nécessite un sponsor au sein de la direction générale permettant son application.
Cette mise en application peut être facilitée par une communication régulière aux différents interlocuteurs sur les gains en termes de cout et de délais associés à l’application du cadre et des processus et par la priorisation des projets les appliquant par rapport aux projets réticents (« politique de la carotte et du bâton »).
Enfin, tout au long de cette mise en place, il est nécessaire de prendre en compte très rapidement tout retour.
Les outils clés
Afin d’assurer la réussite du processus, celui-ci doit être accompagné d’un certain nombre d’éléments.
Les offres de services doivent donner la priorité au respect des standards et contraindre le sur-mesure à des études supplémentaires. Chaque « standard » d’une offre de service est à associer à un template de configuration permettant de limiter les couts et délais de préparation des environnements des applications, ainsi que les couts d’exploitation, mais aussi de limiter le risque d’incidents par la maitrise de la configuration. La mise à disposition de modèles types de supervision des services applicatifs est également un point à ne pas négliger.
Le processus de demande de mise en place d’une architecture validée doit être le plus simple possible pour le métier, le nombre d’informations, minimisé, et la complexité sous-jacente à la demande, masquée. Au besoin, cela passe par la mise en place d’une entité chargée de traduire rapidement une demande de mise en place ou d’évolution de l’existant issue du métier en un ensemble de demandes techniques ciblant les besoins (installation de serveurs, mise en place de machines virtuelles, configuration réseau, ouverture de flux, configuration des équipements de sécurité applicative …).
L’objectif est de rendre attractif le suivi de l’offre standard en le rendant plus simple, plus rapide et moins couteux.
Il ne faut par contre pas bloquer la spécificité si elle ne remet pas en cause le bon fonctionnement ou la sécurité du SI. Elle peut en revanche être plus longue et plus couteuse à insérer, cela se justifiant par les études permettant sa bonne intégration.
Cadrer l’historique pour poser les bases du futur
La bonne gestion de l’insertion d’une application dans un SI passe par un cadre clair et partagé de tous, des processus et outils simples et acceptés, un accompagnement de proximité, facilitant la vie des responsables d’applications jouant le jeu des normes propres SI et reportant le cout de toute complexité sur le métier responsable, sans bloquer les spécificités.
Et ce mode de fonctionnement, bien adapté à une gestion classique des développements applicatifs, peut être une base pour entamer des réflexions sur le mode agile où la définition d’un cadre et la priorisation de l’utilisation des standards restent de bonnes pratiques.
