La révolution digitale est bien en route ! Les Chief Digital Officer ne se comptent plus et Node.JS est désormais partout. Toutes les entreprises, même celles orientées B2B, renouvellent sans cesse leurs frontaux clients et autres applications mobiles afin de satisfaire des utilisateurs toujours plus exigeants.
Un DSI qui se fierait uniquement à toutes ces interfaces dernier cri (responsive design, flat design, progressive webApp…) aurait de quoi paniquer : « Chez Plouf, nous sommes très en retard, il faut tout refaire au sein du SI pour pouvoir construire ce type d’interface » !
Doit-on réellement s’affoler ?
Même si depuis l’extérieur c’est une magnifique voiture de sport qui apparaît, lorsque l’on soulève le capot, on tombe bien souvent encore sur un moteur de 4L (voire de Traction !).
En effet, la majorité des sociétés ayant déjà mis en place des frontaux modernes n’ont pas eu le temps et/ou l’argent (et parfois la volonté) pour moderniser l’ensemble de leur système d’information.
De la magie alors ? Pas tout à fait !
Les frontaux mis en place ne servent en réalité que d’interface utilisateur et les données affichées sont des copies de celles contenues dans les systèmes de gestion. Au mieux, celles-ci sont copiées dans un Data Lake / Data hub avec une couche d’API qui permet de les exposer, au pire elles sont copiées dans une base propre à chaque frontal sans forcément de réflexion sur la gouvernance de ces données (lignage, source(s), qualité, fraicheur – vérité à un instant t, cycle de vie, …).
Dans bien des cas, la mise en place de ces interfaces utilisateur peut se faire car elles se basent quasi-uniquement sur de la consommation de données. Or lorsque les données sont disponibles, il n’est pas extrêmement complexe de monter des frontaux modernes en utilisant les dernières technologies.
Cependant, un certain nombre de problèmes peut subsister, notamment lorsque ces frontaux sont utilisés pour modifier des données qui doivent être prises en compte dans les systèmes de gestion. C’est en effet ces systèmes qui gèrent la complexité des règles métiers, de la qualité des données et ce sont ces mêmes systèmes que l’on ne sait pas remplacer facilement par des outils modernes.
Quels sont donc les principaux points d’attention à surveiller lorsque l’on souhaite mettre en place ce type de frontal digital orienté utilisateur final ?
Définir les cas d’usage, les données attendues associées et la fréquence d’utilisation. Cela permet notamment de :
Dimensionner les solutions à mettre en place (exposition de service par une « application », nécessité de monter un Data Hub pour déporter un grand volume de consultations…).
Vérifier que le nouveau frontal s’intègre bien dans la gouvernance de données, que la traçabilité des données est bien assurée.
Limiter les actions directes sur les données depuis le portail et privilégier la collecte de demandes à traiter en asynchrone au fil de l’eau.
Le portail ne doit être qu’un point de collecte de demandes qui seront transmises et traitées en aval par les systèmes de production en fonction de leurs capacités.
Centraliser les données au sein d’un Data Hub plutôt que de multiplier les copies de bases. Les nouvelles technologies permettent d’allier volumétrie importante et haute performance.
La mise en place d’API (et d’une plateforme d’API management) permet également de découpler les frontaux du reste du SI. Ainsi, la poursuite de la modernisation du SI pourra se faire en limitant les impacts sur les « applications digitales » (et sur le reste du SI). De plus, les API sont aujourd’hui particulièrement efficientes pour les cas de consultation / recherche de données.
Notons tout de même que malgré un découplage bien pensé, on ne pourra pas éviter tous les impacts. Lorsqu’il y a des évolutions structurelles, tous les éléments d’un SI sont susceptibles d’être impactés. Les frontaux modernes développés sur des technologies aujourd’hui matures, restent toutefois relativement facilement évolutifs.
Les frontaux digitaux sont les principaux vecteurs de l’image d’une entreprise vers le monde extérieur. Il est donc primordial de leur accorder de l’importance.
Pour autant, doit-on s’arrêter là ? Probablement pas !
Ces nouveaux usages permettent de développer d’autres pratiques :
Les frontaux digitaux peuvent également avoir une forte plus-value pour des usages internes. Ils évitent les connexions à de multiples applications hétérogènes qui finissent par user les collaborateurs. Lorsque c’est pertinent, le développement de solutions digitales internes pour les collaborateurs est intéressant en termes de UX mais aussi de rationalisation SI.
Les API mises en place pour ces frontaux peuvent éventuellement être exposées à l’extérieur et ainsi être valorisées. Des partenaires, des clients ou des start-up peuvent réutiliser les API exposées et fournir indirectement aux usagers des services de l’entreprise d’une information « propriétaire » sur des canaux externes plus adaptés à ses besoins. Plus généralement, ces nouvelles technologies peuvent induire une transformation du « business model » ou répondre à de nouveaux besoins.
Pour les entreprises les plus avancées, la mise en place de ces frontaux est également l’occasion de profiter de ceux-ci pour faire du tracking du comportement / du parcours digital omni-canal de ses clients. Cette connaissance permet de personnaliser la relation avec un Client, de lui proposer une offre adaptée au bon moment ou de déclencher la Next Best Action quelle qu’elle soit.
On s’occupe uniquement des frontaux digitaux alors ?
Des frontaux dernière génération permettent de faire illusion auprès des utilisateurs et peuvent ainsi servir dans un bon nombre de cas de « cache-misère ». Si ces différents frontaux digitaux que l’on peut mettre en place améliorent le quotidien, il ne faut pas pour autant oublier de continuer la rénovation du reste du SI. Cela reste en effet bien souvent le « Legacy » qui soutient réellement les processus métier et les données de l’entreprise. Il est donc critique et mérite un effort de modernisation adéquate.
Les autres articles qui peuvent vous intéresser
Optimiser la valeur de votre cartographie et de votre documentation
Optimiser la valeur de votre cartographie et de votre documentation
Optimiser la valeur de votre cartographie et de votre documentation avec nos bonnes pratiques![/chapo]
Dans notre monde complexe, la transformation permanente devient un principe de fonctionnement des entreprises. Celles-ci doivent alors choisir les changements qu’il est nécessaire d’implémenter et avec le plus de valeur ajoutée.
Pour faire les bons choix, la connaissance du fonctionnement de l’entreprise est incontournable. Cette connaissance doit être correctement structurée afin que chacun puisse trouver aisément les informations dont il a besoin.
Cartographie et documentation, définition
Une entreprise ne doit pas compter que sur les connaissances de ses employés. Certains peuvent partir et la connaissance qu’ils ont acquise sera alors perdue. Pour se prémunir contre cette perte, une organisation dispose de 2 outils, la cartographie et la documentation :
• La cartographie est une représentation sous forme de listes (des applications, des processus, etc.), de diagrammes et de matrices. • La documentation est l’ensemble de la production sous format type Office (PPT, Excel, Word, etc.) pérenne ou non, créée par des collaborateurs.
Ces deux outils doivent apporter de la valeur et être utiles, sinon ils seront sans intérêt et l’effort à fournir pour les construire et les garder à jour en vain.
La cartographie doit structurer la documentation
A partir de retours d’expériences sur la mise en place d’un système de cartographie et de documentation chez différents clients, la conclusion est que la cartographie et la documentation devraient être complémentaires et cohérentes.
La cartographie est de valeur car elle offre une vue globale et synthétique de l’entreprise selon plusieurs points de vue: stratégique, métier, fonctionnel, applicatif, technique, données, etc. Comme pour un plan de bâtiment, cela permet de connaître le rôle et la structure de chaque étage. Aussi utile soit-elle, cette vue globale n’explique pas comment chaque élément de l’entreprise fonctionne.
La documentation vient alors enrichir la cartographie grâce aux informations détaillées apportées sur chaque élément représenté. Les informations de l’entreprise sont collectées, classées, exploitées et diffusées grâce à la documentation. Elle est utile grâce aux réponses apportées aux différents besoins de connaissance pour assurer le fonctionnement opérationnel et pour mener les projets de transformation de l’entreprise.
Un intérêt certain, mais des freins importants
Malgré la nécessité de la cartographie et de la documentation, dans plus d’un cas, elles sont incohérentes, incomplètes ou caduques. La cause majeure des problèmes rencontrés est l’absence de principes structurants. Ceux-ci doivent apporter la cohérence entre ces deux parties, veiller à un apport réel de valeur et garantir que seulement ce qui est utile à l’entreprise est documenté et/ ou cartographié. En effet, un esprit frugal visant l’adéquation entre les besoins de l’entreprise et la cartographie et la documentation permet de se prémunir contre des efforts avec peu de valeur ou de pertinence.
Les principes régissant la cartographie sont : • Identifier la catégorie des informations (métier, fonctionnelle, applicative, etc.) • Organiser les informations par catégorie (métier, fonctionnel, applicatif, etc.), • Prendre, si possible, la stratégie comme point de départ de l’organisation de la cartographie • Puis structurer la cartographie par couches qui se déduisent l’une de la précédente.
Le schéma ci-dessous illustre la relation entre ces différentes couches qui composent l’entreprise :
Les principes régissant la documentation sont :
Définir les types de documents pour faciliter la classification
Identifier l’objet, le type et la pérennité de chaque document
Associer les documents pérennes à la cartographie à partir de l’objet décrit
Organiser les documents pérennes à partir de la cartographie
Ranger les documents projets par projet
A la fin d’un projet récupérer la documentation pérenne et la ranger selon les principes mentionnés ci-dessus.
Procédez par petits pas.
Le système de cartographie et de documentation peut être construit et géré comme un bâtiment :
Identifier les fondations : les principes structurants
Définir le projet de construction : le guide de modélisation et de documentation
Définir la structure globale du bâtiment : la cartographie synthétique et détaillée
Définir les systèmes utilitaires du bâtiment: les flux d’informations et les liens logiques entre les objets cartographiés
Décrire de manière détaillée chaque élément du bâtiment : la documentation des différents objets de la cartographie.
Gérer chaque projet de rénovation : de chaque projet de transformation récupérer les plans de transformations et les documents pérennes produits.
Les fondations sont les principes mentionnés et qui peuvent être adaptés et enrichis en fonction du contexte de chaque entreprise.
De la même manière que la construction d’un bâtiment doit être maîtrisée et la rénovation également, la construction de la cartographie et sa mise à jour doivent l’être également. Un guide de modélisation définit les règles de cartographie. Un référentiel d’architecture d’entreprise implémente ces règles et assure la maîtrise de la construction de la cartographie. Les différents niveaux sont liés entre eux et une cohérence globale existe entre les informations. Ainsi, la valeur apportée par la cartographie est mise à disposition du plus grand nombre de manière structurée et adaptable aux besoins diverses dans l’entreprise.
Si possible, le point de départ pour la construction de la cartographie devrait être la stratégie. A partir de celle-ci le métier de l’entreprise est décrit. La réalisation du métier engendre des besoins pour l’entreprise qui sont catégorisés dans une vue d’ensemble fonctionnelle. Comme le système informatique et technique de l’entreprise existe pour répondre aux besoins de l’entreprise, la vue d’ensemble fonctionnelle le structurera.
Chaque étage de la cartographie de haut niveau est ensuite décrit en détail et enrichi des échanges d’informations. L’identification des liens entre les différents étages de la cartographie vient compléter cette démarche et est implémentée dans le référentiel d’architecture d’entreprise.
Une fois la cartographie structurée et le référentiel d’architecture d’entreprise mis en place, la base d’organisation de la documentation pérenne est assurée. Les principes de structuration de celle-ci peuvent alors être mis en pratique. La documentation deviendra bien plus utile, grâce à une organisation qui a du sens et qui évite la recherche inutile des informations.
Pour les projets de transformation, le référentiel d’architecture d’entreprise doit servir de point d’entrée dans la phase de cadrage afin d’offrir une vision partagée et globale du fonctionnement de l’entreprise. Les documents liés à la vie du projet peuvent être gérés grâce au référentiel ou séparément. A la fin du projet les différentes transformations apportées par celui-ci seront reportées dans la cartographie et la documentation pérenne produite ou mise à jour y sera associée. Cette inclusion de la cartographie et de la documentation dans les processus projet fera que celles-ci ne seront réalisées qu’au niveau strictement nécessaire. Cela libère du temps pour réaliser le projet au lieu de passer son temps à le documenter.
Différentes méthodes d’optimisation, souvent complémentaires
Mettre en place un système de cartographie et de documentation est important. Par contre, sans l’optimiser et le garder à jour, il perd vite de son intérêt. La pérennité de ce système peut être assurée par des solutions complémentaires comme l’agilité, le Lean ou le principe 5S.
Le principe 5S facilite l’ordre mais aussi la rigueur afin de prévenir les écarts.
Il préconise de structurer un système par catégories d’éléments, d’identifier les anomalies et de viser toujours la rigueur. Ainsi, 5S permet à partir des principes sur la cartographie et sur la documentation de constituer des systèmes ordonnés et cohérents. Cet ordre met en lumière ce qui est en double et réduit le temps de recherche de l’information. Par contre, 5S ne répond pas au besoin de cartographier et de documenter seulement ce qui est demandé.
Le Lean vient alors comme solution au problème de cartographier et de documenter le juste nécessaire. En effet, son principe de base est d’ajuster la production à la demande. Le Lean propose de regarder ce qui est demandé le plus, par qui, et pour quelle raison et s’organiser en conséquence. L’audit des chaînes de production documentaire et de cartographie fait ressortir ces éléments. Ainsi, le système de cartographie et de documentation déjà ordonné par le 5S, se voit allégé au juste nécessaire avec des temps de production optimisés.
L’agilité apporte une perspective orientée valeur des documents et de la cartographie. Seules les cartographies et les documents apportant le plus de valeur perdurent et sont traités en priorité. Au lieu de tout garder à jour comme parfois demandé, l’effort documentaire est concentré sur ce qui apporte le plus de valeur.
Ensemble, ces trois méthodes produisent un système ordonné par le 5S, rendu pertinent et accéléré grâce au Lean, et optimisé en termes de valeur grâce à l’agilité.
Pour conclure, la cartographie et la documentation doivent former un tout cohérent. Elles sont régies par des principes différents qui visent à la fois l’apport de valeur et limitent l’effort à ce qui est utile. Ce système se construit petit à petit comme un bâtiment. La maîtrise des impacts de la transformation de l’entreprise sur la documentation et sur la cartographie est réalisée grâce à un bon référentiel d’architecture d’entreprise et une démarche optimisée mêlant l’agilité, le Lean et le 5S.
Ensemble, la cartographie et la documentation cohérentes facilitent la réduction du time-to-market et l’élimination des redondances par une information structurée et rapide d’accès.
Le service Cloud d’Amazon, AWS, a été victime récemment d’une panne majeure de son service de stockage simple nommé S3. Cette brique technique est très populaire et répandue pour implémenter des applications ou services hébergés chez AWS. Pour vous donner une idée de l’ampleur de son utilisation depuis son lancement en 2006, ce service permet aujourd’hui de stocker des dizaines de milliards d’objets. D’autres briques techniques chez Amazon peuvent s’appuyer sur ce stockage pour fonctionner comme le service Elastic Compute (EC2), Elastic Block Shop et Lambda. Cette panne de service a eu donc pour effet d’engendrer des perturbations majeures pour plusieurs applications hébergées chez AWS :
La messagerie instantanée Slack
Le service de stockage en ligne Box
Le service de livraison des pizzas Dominos
Les sites web communautaires Reddit et BuzzFeed
Heureusement la cause de l’incident a vite été repérée et corrigée par l’hébergeur. En revanche, elle a tout de même engendré des indisponibilités de plusieurs heures pour certaines de ces applications. Est-ce que les entreprises ayant pris la décision de faire appel à du Cloud Public doivent pour autant entrer en mode panique et rapatrier leurs applications et données chez eux ? La réponse est NON bien entendu. Amazon a rapidement communiqué que la nature de la panne du service S3 était due à une erreur humaine déclenchée par un employé ayant toutes les autorisations et qui aurait soumis une commande manuelle avec de mauvais paramètres. De plus, l’impact de la panne se limitait uniquement au « datacenter » de la région Virginie située sur la côte Est des Etats-Unis. Une telle erreur aurait pu donc se produire n’importe où, chez n’importe quel fournisseur d’hébergement y compris dans vos propres « datacenters ».
Cet incident nous rappelle seulement qu’il ne faut pas se fier uniquement à la résilience de la couche infrastructure Cloud, même chez le leader du marché, pour garantir une haute-disponibilité. Il est bon de rappeler ici que les engagements de service (SLA) pour la brique S3 ne sont que de 99,99%. Ceci signifie tout de même une indisponibilité potentielle de 87,5 heures pour une année ! Le fournisseur de service de vidéo en ligne Netflix est aussi hébergé chez AWS et il a pourtant été épargné par la panne du service S3. Une étude réalisée en interne en 2014 avait permis d’estimer une perte de 200 000$ de chiffre d’affaires pour une heure d’arrêt de la plateforme. Nous pouvons donc estimer qu’en 2017 le coût total d’une panne de 4 heures aurait pu leur coûter plus d’1 million de dollars. Ceci est sans compter l’impact négatif sur la réputation et image auprès de leurs usagers qu’une telle panne aurait pu occasionner . En tenant compte de ces besoins, les architectes techniques de Netflix ont conçu une architecture cloud résiliente basée sur plusieurs zones AWS. Ceci leur permet donc d’éviter toute perte de service en cas de panne ou incident et d’avoir un meilleur SLA que les 99,99% promis par le fournisseur.
L’impact financier de l’arrêt de votre application métier est probablement moindre que celui de Netflix. Vous n’avez peut-être pas non plus un fournisseur Cloud ayant plusieurs « datacenters » dans différentes régions comme peut l’offrir AWS. Pour autant déployer vos applications sur du Cloud Computing ne vous affranchit pas du tout des services d’un architecte technique, au contraire ! Celui-ci, s’il déroule une démarche prenant compte des besoins métiers et des exigences non fonctionnelles, saura vous proposer des scénarios d’architectures résilientes. L’architecture finale sera plus chère et complexe sans doute. Il ne faut pas oublier dans ce cas d’estimer l’impact et la probabilité d’une perte de service avant d’évaluer si ces coûts supplémentaires en valent la chandelle.
Sources d’information pour incident AWS S3 survenu en mars 2017 :
Le groupe Rhapsodies Conseil recrute 20 nouveaux collaborateurs en 2016.
Nous recherchons des Consultants, Managers et Senior Managers avec des expertises technologiques et métier autour de la Transformation Digitale, l’Architecture des Données, l’Architecture SI et Technique, l’Architecture Métier, la Gestion des Risques, les Moyens de Paiement, la Monétique, le Pilotage de la Transformation, le Sourcing et la Performance Economique.
Accompagnez le développement de notre cabinet tout en faisant évoluer vos compétences.
Sourcing & Architecture : 2 stratégies complémentaires au service de la performance
Nombreux sont les clients qui, à l’occasion de leurs projets d’externalisation, découvrent leur patrimoine applicatif. Celui-ci constitue pourtant un des éléments de calcul des coûts associés aux contrats de prestations négociés avec les fournisseurs. Comment tirer parti des opérations d’externalisation pour rationaliser son patrimoine applicatif ? et réciproquement… Entretien avec Franck Gerbier et Jean-Michel Goubert, directeurs associés de Rhapsodies Conseil.
Qu’est-ce qu’une stratégie de Sourcing efficace ?
Dans un marché fait principalement de renouvellement de contrats, nombre d’entreprises externalisent sans objectifs clairement définis ni partagés et n’ont pas toujours une vision claire de la réalité de leurs coûts.
Au-delà de la problématique unique des coûts, il est nécessaire d’identifier l’ensemble des objectifs poursuivis pour définir une stratégie de sourcing efficace (rationalisation des prestataires, recentrage sur un coeur de métier, accélération de la montée en compétences vers de nouvelles technologies, évolution vers le cloud, etc.) Il est aussi indispensable d’établir un état des lieux de la situation selon différents axes ; qualitatif, technique, financier et organisationnel. C’est la parfaite connaissance de la situation existante et la définition précise de la cible à atteindre qui permettront de définir la stratégie de sourcing gagnante.
Découvrez l’intégralité de l’entretien Sourcing & Architecture paru dans dans le dossier spécial « Conseil & Finance » de la revue de Polytechnique La Jaune et la Rouge.
L’une des principales missions de l’urbaniste est de favoriser la souplesse d’adaptation du système d’information avec des moyens simples, peu coûteux et non intrusifs, tout en apportant une aide concrète aux équipes de projet. Traditionnellement, l’urbaniste est considéré comme un empêcheur de tourner en rond. Il est perçu comme l’auteur de chartes et de normes théoriques, que personne n’applique vraiment. Il en résulte un certain désenchantement, et un fort turn-over parmi la population des urbanistes.
Sans pour autant renier cette mission, cette tribune milite pour un urbanisme opérationnel, qui doit favoriser la souplesse d’adaptation du S.I. avec des moyens simples, peu coûteux et non intrusifs, tout en apportant une aide concrète aux équipes de projet. Exemple concret : le choix de progiciel.
Les deux missions de l’urbaniste
Pour définir le travail de l’urbaniste et ses enjeux, on a souvent recours à la métaphore de la ville. Comparaison pertinente, même si les contraintes du système d’information sont plus ou moins faciles à contourner. En effet, s’il est plus facile d’augmenter le débit d’une ligne réseau que d’élargir une rue, les erreurs et plus encore le manque d’anticipation se révèlent souvent très coûteux… des années après.
Penser l’organisation du territoire, donc. Appliqué au SI, le problème revient à découper celui-ci en blocs à la fois suffisamment autonomes, reliés entre eux de manière efficiente, et en mutualisant au mieux les composants. Si la problématique est relativement simple pour les composants techniques – les SGBD, les middleware, le poste de travail et ses applications de bureautique – , plusieurs approches ont cours pour déterminer les frontières applicatives : par fonction de l’entreprise, par service (au sens SOA), par domaines d’objets…
Soyons humbles : il n’existe pas de réponse toute faite. Pour prendre le seul exemple du pilotage d’entreprise, il peut être judicieux soit de l’isoler, afin de mutualiser les outils d’analyse et de reporting, soit de l’intégrer aux systèmes opérationnels (ERP…) pour faciliter le processus d’analyse de bout en bout, et éviter d’alimenter de coûteux datawarehouses. Sur ce point, le discours des éditeurs, variant au gré des alliances, n’éclaire pas vraiment les choix.
Pour noble et vitale qu’elle soit, cette première mission de l’urbaniste rencontre des limites d’application : tout d’abord, les projets de refonte significative du SI étant rares, le chantier est perpétuel et les victoires rapides demeurent exceptionnelles. Par ailleurs, les chartes d’urbanisme sont difficilement compatibles avec la mise en oeuvre de progiciels, pour une raison bien simple : l’objectif de l’éditeur est de pouvoir mutualiser son offre vis-à-vis de clients de métiers différents, d’organisations et de stratégies différentes.
Un garde-fou : les points de précaution
A notre point de vue, l’urbaniste doit assurer une seconde mission : veiller à ce que les équipes de projet respectent le minimum de règles de conception qui permettront de faire évoluer la solution facilement, sans paramétrage ni re-livraison de code. Point important, ces règles s’appliquent aussi bien aux progiciels qu’aux développements spécifiques. Problème : ces règles sont souvent abstraites, peu parlantes pour les experts métier et les maîtrises d’ouvrage.
La solution que nous proposons est simple et rapide : au lieu de règles, l’urbaniste fournit aux équipes projet un questionnaire de points de précaution, exprimés en termes métier. Exemple : est-il possible de modifier l’identifiant d’un client sans perdre l’historique des échanges avec ce client ? Pour déployer la solution sur une nouvelle filiale, est-il possible d’ajouter une nouvelle langue sans faire appel à l’éditeur du progiciel ?
Comme on le voit, les questions sont précises, conçues pour appeler une réponse rapide et simple : par oui ou non. Chaque réponse négative identifie immédiatement un risque de rigidité, un écart par rapport à des bonnes pratiques, dont l’impact peut être immédiatement évalué par l’ensemble des parties. Les points de précaution incontournables sont priorisés d’un commun accord, en fonction du métier et des perspectives d’évolution de celui-ci : intégration de nouveaux partenaires, déploiement plausible à l’international sous 3 ans… Conséquence logique de la démarche, l’urbaniste peut aller jusqu’à exercer un droit de veto lorsque ces points ne sont pas traités de manière satisfaisante.
En pratique, nous avons pu vérifier sur le terrain que le questionnaire permettait de hiérarchiser des progiciels entre eux, et par conséquent de discriminer les moins agiles. Bien entendu, il ne s’agit que d’un élément supplémentaire de choix, mais qui contribue à objectiver la décision finale.
Quelles compétences pour l’urbaniste ?
On le devine, cette approche transforme le rôle de l’urbaniste. De donneur de leçons, il devient fournisseur de conseil : il apporte un éclairage complémentaire, parfois décisif, sur des choix structurants. Son apport est reconnu, facilement accepté, et contribue à valoriser la fonction.
Pour arriver à remplir ce rôle, il est souhaitable d’avoir une expertise en modélisation et en fabrication de logiciel. Des connaissances métier sont également utiles pour traduire les règles de conception en points de précaution spécifiques au contexte. Il arrive de trouver dans des appels d’offre des questions formulées ainsi : le progiciel est-il multi-devise ? Bien entendu, l’éditeur répond oui. Dans le détail, même dans des domaines métiers aussi banalisés que la comptabilité, le traitement multi-devise varie d’un progiciel à l’autre. L’urbaniste est là pour affiner la question : le progiciel permet-il à un client de régler dans plusieurs devises, d’être titulaire de plusieurs contrats dans des devises différentes ?
Ne rêvons pas : le droit de veto de l’urbaniste n’est pas pour demain. Rares sont les urbanistes à disposer de budgets autonomes, d’équipes de conseil opérationnel à même d’apporter un support aux équipes de projet. Ce que nous proposons ici n’est qu’un modeste petit pas vers un renforcement légitime de l’autorité de l’urbaniste.
