Discussion:Urbanisme (système d'information)
- Admissibilité
- Neutralité
- Droit d'auteur
- Article de qualité
- Bon article
- Lumière sur
- À faire
- Archives
- Commons
J'ai créé un article urbanisme (système d'information), alors que l'article urbanisation existait déjà. Je mets donc un redirect vers urbanisation, et je sauvegarde en page discussion le contenu de l'article urbanisme. Pautard 29 mai 2006 à 08:50 (CEST)
Le terme urbanisme de système d'information est de plus en plus employé, au moins en France, pour désigner une démarche de redéfinition ou de conception globale du système d'information d'une entreprise ou d'un organisme.
Dans les premiers temps de l'informatique, dans les années 1960-1970, on avait coutume d'employer une autre expression : on parlait de schéma directeur du système d'information.
Les deux expressions sont empruntées à la profession du bâtiment et des travaux publics, par analogie avec les niveaux d'intérêt et les phases de projet correspondantes.
Sémantique[modifier le code]
Les correspondances entre les systèmes d'information et le BTP sont les suivantes :
- Urbanisme et schéma directeur : entreprise -> ville,
- Etude préalable : Domaine de l'entreprise -> quartier d'une ville,
- Etude détaillée : Projet à l'intérieur d'un domaine -> bâtiment,
- Réalisation : Programme -> lot à l'intérieur d'un bâtiment.
Le terme urbanisme de système d'information fait appel à des concepts exclusivement fonctionnels.
Le terme d'architecture de système d'information peut désigner soit l'architecture fonctionnelle, soit l'architecture technique.
Historique[modifier le code]
Dans les premiers temps de l'informatique (années 1960-1970), le schéma directeur du système d'information visait à donner une vision d'ensemble de l'entreprise, avec les priorités des domaines à informatiser, et une évaluation approximative des charges de travail et du coût des projets, afin d'établir un retour sur investissement. L'objectif était alors d'automatiser les tâches administratives, les gains étant obtenus par la diminution des tâches répétitives, et la réduction correspondante du personnel administratif, pouvant être employé à d'autres tâches.
La méthode la plus employée alors était RACINE, une sorte d'équivalent de MERISE au niveau entreprise. On retrouvait donc des concepts assez similaires.
Dans les années 1990, l'obsolescence des systèmes d'information par rapport aux contraintes techniques imposées par le passage informatique à l'an 2000 (voir aussi Y2K) et, en Europe, par le passage à l'euro, ont nécessité de faire des états des lieux de l'ensemble des systèmes, afin d'évaluer les impacts et les plans d'actions nécessaires. Ces programmes, organisés le plus souvent transversalement dans les entreprises, ont souvent conduit à remplacer presque complètement les systèmes d'information des entreprises par des progiciels (ERP), dont les fonctions étaient censées remplacer celles des anciennes applications spécifiques, en mettant en cohérence les données principales des entreprises. Dans une minorité de cas, les entreprises ont choisi de rénover leurs anciennes aplications. On constate que dans le secteur industriel, la proportion d'applications remplacées par des ERP a été beaucoup plus forte que dans le secteur bancaire, où globalement les anciennes applications spécifiques ont plus souvent subsisté .
Ces programmes ont consisté en des démarches de redéfinition des systèmes d'information, que l'on a qualifiées alors d'urbanisme de système d'information.
Méthodologie[modifier le code]
La méthodologie employée pour un programme d'urbanisme de système d'information consiste à cartographier le système d'information de l'organisme. Le terme de cartographie est utilisé à nouveau par analogie avec la profession du bâtiment et des travaux publics.
Les cartographies ont principalement pour objectif de définir :
- l'état initial du système d'information,
- la cible,
- les phases transitoires, et les contraintes d'enchaînement des projets.
Pour chaque état, il est nécessaire de définir les données principales, les applications, et les flux ou interfaces entre les applications.
Pour les données principales, on parle encore de données de référence, ou bien de données maîtres, ou encore de métadonnées. Ces termes sont sensiblement équivalents.
En fait, ce qui est constant dans une entreprise, sauf cas de diversification, ce sont les données qui décrivent son métier. Il est vital de disposer d'un référentiel permettant de définir les données maîtres : clients, produits/services, organisation, fournisseurs,... Ce référentiel, qui n'a pas vocation à être un dictionnaire exhaustif de toutes les données dans tous leurs détails, doit au moins pouvoir décrire les propriétés principales des métadonnées (définition, quelques propriétés importantes, structure), celles qui sont communes à au moins deux domaines de l'entreprise.
Il existe des normes qui permettent d'atteindre un certain niveau de cohérence dans la définition de certaines données. Pour les données spécifiques à l'entreprise, c'est à celle-ci de définir ses propres standards.
La méthodologie doit tenir compte de l'existant, et être itérative.
Traditionnellement, on pensait dans les années 1970-1980 qu'une démarche de schéma directeur, lorsqu'elle était nécessaire, devait intervenir de préférence avant les études préalables, les études détaillées et les études d'architecture technique. Cette conception correspondait au fameux cycle en V.
En pratique, cette conception a montré ses limites : 1) Les erreurs de conception ne pouvaient pas être prises en compte au fil de l'eau, 2) Dans les années 1990, les contraintes de délai des projets ont nécessité de mener en parallèle les différents projets et leurs phasages (études, architecture technique et lots de réalisation), en gérant des contraintes d'enchaînement complexe.
Il est apparu qu'une des bonnes manières de gérer les contraintes d'enchaînement était de cartographier les systèmes d'information à partir des données de référence, et de situer les applications par rapport aux données. La cohérence du système d'information est obtenue en permanence par les données des domaines traités par les projets dans chacune de leurs phases d'avancement.
Enjeux actuels de l'urbanisme de SI[modifier le code]
Depuis le début des années 2000, le web conduit à une très grande ouverture des entreprises sur leur environnement. Les facilités apparentes offertes par le web ne doivent pas faire oublier deux enjeux fondamentaux :
- les contraintes réglementaires : loi de sécurité financière, mais aussi en Europe les directives européennes de plus en plus nombreuses et complexes, ainsi que les demandes de la société civile sur une meilleure transparence (communication sur la responsabilité sociétale à moduler par un plan d'intelligence économique adéquat...),
- la surveillance de la concurrence, à une échelle mondiale : que font les concurrents américains, japonais, chinois, indiens,...
Dans ce contexte, les entreprises sont amenées à travailler bien davantage en réseaux, échangeant avec leurs parties prenantes de plus en plus d'informations, qui sont d'ailleurs plus ou moins structurées : messages électroniques, documents, dossiers etchniques, plans... Le volume d'informations échangées entre entreprises explose chaque année grâce aux possibilités techniques offertes par les réseaux, et ces informations sont le plus souvent non structurées.
Ceci pose un enjeu évident de sécurité : comment préserver le capital d'expertise de l'entreprise ? Cet enjeu ne se traduit pas seulement par une sécurité informatique au sens strict : du moins, la confidentialité n'est-elle pas la seule en jeu. Il faut aussi envisager la sécurité sous l'angle de l'intégrité et de la disponibilité. Une approche strictement technique ne suffit encore pas, dans la mesure où les diffusions intempestives d'informations (via les colloques, la mise d'informations en source ouverte sur des sites web, des blogs...) peuvent encourager les oreilles indiscrètes.
D'autre part, la prise en compte des données juridiques nécessite une approche qui dépasse la simple analyse par la sécurité informatique.
Limites des méthodologies actuelles[modifier le code]
TODO: UML n'est pas une méthode mais un language unifiant les languages utilisés par différentes méthodes!
On constate que la méthodologie la plus couramment employée actuellement, à savoir Unified Modeling Language (UML) présente certaines insuffisances :
1) Cette méthode est surtout destinée aux maîtrises d'œuvre, c'est-à-dire aux informaticiens. Elle est peu adaptée aux maîtrises d'ouvrage : les concepts sont très ésotériques et très difficilement compréhensibles par des utilisateurs non formés.
2) D'autres enjeux liés à la nature des informations et aux nouveaux besoins des entreprises sont mal pris en compte.
Cas où une démarche d'urbanisme est nécessaire[modifier le code]
(à compléter)