Lire Ecrire Compter Coder est le titre d’un petit livre paru il y a un an aux éditions FYP. Il intéressera tous ceux qui s’intéressent à l’enseignement de l’informatique, mais il va plus loin, il pose aussi la question de la bonne utilisation de la société numérique.
On l’aura noté, le titre est à l’infinitif. La quatrième de couverture, quant à elle, se conjugue au définitif : on peut y lire que l’ouvrage « traite de la nécessité d’apprendre le code pour toutes les générations et explique comment y parvenir ». Faut-il faire comme l’Estonie, qui vient de rendre obligatoire l’enseignement de l’informatique dès l’âge de 7 ans ?
Mais à l’intérieur du livre, le propos est plus nuancé.
Les auteurs expliquent que l’apprentissage du code ne résout pas tout : le code est un moyen et pas une fin en soi. Après tout, beaucoup de personnes savent utiliser une machine à laver ou une voiture, sans pour autant savoir vraiment comment elle fonctionne, et encore moins comment la réparer !
Un des points intéressants de l’ouvrage est de montrer que l’enseignement du code relève de l’apprentissage par l’action. Autrement dit, de l’expérimentation. Tout comme naguère on apprenait la biologie des réflexes en excitant une patte de grenouille, l’apprentissage par la pratique est souvent nettement plus efficace que la théorie, et en tous cas, la renforce.
Le code se découvre par l’expérimentation : ceci ravira les tenants de certaines pédagogies ! Il est bien connu que dans beaucoup de domaines, la technique a précédé la science : en d’autres termes on a découvert l’utilisation pratique du feu bien avant d’en comprendre la chimie… Le parallèle avec la chirurgie est particulièrement éclairant : le chirurgien apprend beaucoup en disséquant puis en opérant, la connaissance théorique du corps ne suffit pas.
Le code apprend l’algorithmique, il apprend à penser et à formaliser une méthode. Et tout cela dans un but concret : il ne s’agit pas de coder pour coder, mais de coder pour résoudre un problème. Tester le code permet immédiatement de vérifier si la méthode fonctionne : lorsqu’on se trompe, on peut recommencer, et il y a souvent plusieurs solutions possibles. Tout comme en Open source, l’apprenant est valorisé par la possibilité d’améliorer le fonctionnement d’un code existant, ou de découvrir de nouvelles méthodes. De plus il est largement possible d’apprendre de manière autonome, le transfert de connaissance ne se fait plus seulement dans le sens professeur => élève. Au contraire, on peut apprendre en groupe de pairs : le parallèle est évident avec les méthodes agiles ! L’apprentissage ne se fait plus en « présentiel » (le professeur face à la classe). Autre avantage : il n’est plus nécessaire d’apprendre la même chose à tout le monde…
L’apprentissage du code peut également être un moyen ludique de faire réfléchir à des règles de société. Un des exemples cités concerne la découverte du code de la route grâce à la programmation des feux de croisement.
Savoir coder est également bien utile pour comprendre le monde qui nous entoure – par exemple, comment les entreprises font usage des technologies pour nous proposer des produits et des services ciblés. Mais aussi, comment les individus peuvent orienter les choix de société : à l’image de l’Open source, tous les citoyens peuvent collaborer et influer sur les lois qui nous gouvernent, ces lois n’étant pour les auteurs que le code qui régit le fonctionnement de la société. Il est donc important de ne pas laisser la production de ces codes dans les mains d’une petite fraction d’intérêts. En la matière, l’avènement de plates-formes comme Change.org, qui permet à des citoyens de pétitionner, montre que le chemin à accomplir est encore très long…
Le dernier tiers de l’ouvrage est consacré aux pistes possibles pour apprendre à coder aux enfants et aux adultes. Les auteurs y présentent de nombreuses expériences de manière factuelle, y compris celles qui ne vont pas dans le sens de leur discours. Une preuve d’objectivité qui les honore.
Lire Ecrire Compter Coder, de Frédéric Bardeau et Nicolas Danet, disponible sur toutes les bonnes plates-formes web.
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.
Quelle est la fonction d’un stylo ? A cette question, 99% des personnes interrogées répondront spontanément : à écrire, bien sûr !
L’architecte fonctionnel fait partie des 1% restants. Pour lui, la fonction du stylo est de libérer un fluide permanent sur un support durable. On l’oublie souvent, ce n’est pas le stylo qui écrit, mais la main qui le tient !
Confondre usage et fonction n’est pas très grave dans la vie quotidienne. Mais pour l’architecte, la différence est fondamentale. Impossible de concevoir un système sans comprendre comment il fonctionne !
Plus important encore, l’architecte fonctionnel est toujours à la recherche de mutualisations. Or, ce sont les fonctions que l’on mutualise. Notre bon vieux stylo n’a qu’une seule fonction, mais il est apte à de nombreux usages : écrire, mais aussi dessiner, approuver un document par une signature, ou encore différencier les vêtements de nos enfants par une marque qui nous permettra de les récupérer (les vêtements, pas les enfants) à la sortie de l’école…
Analyser la fonction pour bien construire
Comme son nom l’indique, la fonction décrit le « comment » (comment ça marche) alors que l’usage décrit le « quoi » : ce qu’on peut faire avec.
Prenons l’exemple des véhicules à moteur : en majorité, leur fonctionnement repose sur la combustion de carburant. Pour les construire, pour en optimiser le rendement, il faut comprendre les lois universelles de la thermodynamique. Ces lois s’imposent à tous, constructeurs et conducteurs.
A l’inverse, l’usage des véhicules peut être « customisé », en grande partie adapté à chacun, ou presque : quel rapport entre une moto, un camion de 35 tonnes, ou un 4×4 ?
Certaines ruptures technologiques permettent de modifier les usages, d’autres non. L’arrivée des véhicules électriques, par exemple, n’a guère modifié les usages : avec une voiture électrique, on ne peut pas faire plus de choses qu’avec un véhicule à moteur, et même plutôt moins dans l’état actuel des techniques. En revanche, optimiser leur fonctionnement demande à comprendre d’autres lois : celles de l’électromagnétisme, et du stockage de l’électricité.
Identifier les fonctions à mutualiser
Différencier la fonction de l’usage est également indispensable pour identifier les possibilités de mutualisation. Au 19ème siècle, l’essor de l’industrialisation ne fut possible que par la mutualisation : la gravure ci-dessous montre des dizaines de machines à filer alimentées par une seule machine à vapeur, au moyen de multiples poulies.
En langage d’aujourd’hui, un architecte fonctionnel pourrait décrire cette solution en ces termes : les ingénieurs de l’époque avaient mutualisé la fonction la plus coûteuse, transformer l’énergie thermique en énergie cinétique. Ils l’ont implémentée dans un seul composant : la machine à vapeur. Ensuite grâce à un système d’échange – arbres de transmissions, courroies, et poulies -, ils ont mis à disposition cette énergie sous forme de service, prête à utiliser par des dizaines de machines.
On peut noter au passage que ces consommateurs de services pouvaient en faire des usages différents : carder, filer, tisser…
Application aux systèmes informatiques
Tout comme dans une manufacture, la fonction est mutualisable aussi dans un système informatique. Par exemple, la composition de document est utilisable pour de nombreux usages : éditer des propositions, des contrats, des relevés de compte, ou encore des messages publicitaires. C’est ce qui explique le succès des outils d’éditique.
De même, on peut utiliser les mêmes formules pour calculer les frais à facturer à ses clients, et les commissions à verser à ses partenaires. Pour autant, rares les entreprises qui ont dévolu ces deux usages à un composant logiciel unique ! Et pourtant, ces calculs sont souvent complexes, et avoir à maintenir un seul moteur de calcul coûterait bien moins cher.
L’analyse fonctionnelle, c’est l’analyse de la valeur
Identifier la fonction pour la mutualiser est une des clés de la création de valeur, que ce soit dans la téléphonie mobile, dans la multiplication des outils de médiation (middlewares, ESB, EAIs…) qui mutualisent les fonctions d’échange ; et bien entendu dans le Big Data, promesse d’une exploitation fine des données qui commence à frôler les capacités de l’intelligence humaine.
L’évolution des technologies fait que de nouveaux champs du possible s’ouvrent à la mutualisation ; de plus en plus de fonctions sont mutualisables.
Quant au stylo, le clavier et le document numérique l’auront bientôt relégué au rayon des antiquités. Je vais quand même en conserver quelques-uns, par nostalgie, et pour me gratter l’oreille au cas où …
Comment payer mon abonnement si mon fournisseur se situe en Belgique et moi à Tourcoing à 3 kilomètres de là ? Ou, plus sérieusement, comment accompagner la stratégie de Lisbonne ? Transformer l’Europe en une zone économique cohérente, favoriser la liberté des mouvements de personnes et capitaux, créer une réelle cohésion de pays disparates.
Cette idée s’est déclinée dans mon domaine, les paiements, par un acronyme simple : SEPA. Single Euro Payment Area. La mise en place de SEPA répondant à une volonté louable : mettre en place des moyens de paiement universels, efficaces et sécurisés.
Dans les faits, la mise en place de SEPA s’est traduit par la définition de règles – techniques et fonctionnelles – (normes ISO 20022, R-transactions, cycle des SDD, mandats…) complexes et contraignantes à mettre en œuvre.
Assez rapidement, SEPA est devenu l’arlésienne. Beaucoup d’articles et de conférences de toutes parts. Mais surtout de nombreux reports.
Mais ça y est, SEPA a été lancé en France.
Aujourd’hui, le démarrage, au forceps dans certains cas, est achevé.
Après une année de rodage, on peut tirer les premiers bilans de cette migration. Les tuyaux permettant les échanges sont en place et fonctionnent bien. Les outils permettant les transferts entre comptes sont en fin de rodage. Les organisations inter bancaires permettant le règlement des litiges sont opérationnelles.
Le chèque poursuit son lent déclin face à la carte et les virements (SCT) et prélèvements (SDD) ont définitivement remplacé les virements et prélèvements. Reste encore en circulation quelques moyens de paiements particuliers à la France comme les TIP, télé règlements et effets de commerce.
Novembre, nouveau mois clé de l’EPC
Dans ce nouveau cadre, l’EPC (European Payment Council, organisme qui définit les règles de fonctionnement des SCT et SDD) offre une nouvelle régularité à ses évolutions. Pas de keynote mode Apple, mais la définition d’un cycle régulier de diffusions et de mises en œuvre des règles.
Désormais c’est en novembre que l’EPC diffusera les règles des montées de versions (les rulebooks) mis en œuvre en novembre de l’année suivante. Ainsi, l’année 2015/2016 marque un gel des évolutions entre janvier 2015 et novembre 2016.
Quels impacts ?
A ce jour, la très grande majorité des transactions passe sans difficultés. Les banques et les grands remettants se sont adaptés. Des solutions ont été développées pour gérer les cas complexes posant encore problèmes.
Cependant, et malgré ces efforts, des blocages subsistent : la gestion des premiers SDD émis entre deux acteurs, la modification des mandats, la gestion des BIC / IBAN…
La gestion de ces – encore trop nombreuses – exceptions coûte cher à tous : paiements retardés ou empêchés, interventions manuelles, tensions entre les débiteurs et leurs créanciers, émissions en doubles.
Toutes les banques et tous les grands remettants gaspillent temps et argent pour gérer ces impacts. Une grande banque monopolise plus de 3 ETP rien que pour traiter les réactivations de RUM et le traitement des BIC/IBAN erronés. Dans ce middle office, les traitements manuels occupent environ la moitié des personnes en poste.
Les réponses de l’EPC : les nouveaux Rulebook
SEPA entre dans une nouvelle phase.
Après la décennie de définition des règles et principes, la migration des SDD et l’année de stabilisation technique, des leçons ont été tirées visant à clarifier et simplifier ces outils.
Les demandes des banques et des utilisateurs sont progressivement intégrées aux rulebooks.
Ainsi, en novembre 2015, une première simplification entre en application : donner la possibilité de modifier plusieurs paramètres d’un mandat en une seule fois. Imaginez. Deux entreprises fusionnent. Pour modifier les mandats, il faut d’abord modifier le nom des entreprises. Premier mandat. Puis modifier l’ICS (la référence du créancier) commun. Deuxième amendement.
De même avec ce nouveau rulebook, les principes de signature électronique sont clarifiés.
En début 2016, une nouvelle modification importante arrive : l’IBAN only. Le BIC disparaît. Dès lors, l’émetteur d’une opération n’aura plus à se soucier de la banque destinataire. Seul l’IBAN compte, charge à la banque d’identifier la banque destinataire et de lui faire parvenir les fonds.
Enfin, novembre 2016 marque une grande simplification des SDD.
1.1 Une réduction des délais
Aujourd’hui, la règle des délais à respecter pour la présentation d’un SDD est la suivante : 5 jours pour une première occurrence (First) ou pour un SDD unique (OneOff) et 2 jours pour les autres (Rcur), sauf si la banque en fait la demande et propose un règlement en une journée par l’intermédiaire d’un SDD Core 1.
En novembre 2016, la règle sera de respecter une journée entre l’émission et le traitement. Plus simple.
1.2 Une simplification des cycles
Fini les First !
Voilà comment nous pouvons résumer l’évolution à venir.
Avec ces trois mots, entreprises et banques vont être soulagées de bien des maux.
A ce jour, le cycle des SDD est le suivant : émettre un premier SDD (First) au cours duquel le mandat est référencé. Puis émettre les occurrences suivantes (RCUR) avec la référence de mandat (RUM) validée.
Imaginez le résultat pour les créanciers / débiteurs / banques. Lors du rejet de la première opération ce qui invalide le mandat, commence le grand jeu du « ce n’est pas moi, c’est lui ».
Dans le cas du middle office bancaire évoqué plus haut, cela se traduit par « et, gus, un rcur sur un rum invalide d’un first ko fait planter la chaine et le client il est en panade avec l’autre qui veut ses fond sinon c’est 10%, et le confrère y veut rien savoir, faut checker la rum et la valider manuellement »
Bon, en français ça donne, « un créancier vient d’émettre une demande de prélèvement sur un mandat non valide en raison d’un premier prélèvement non traité. Notre client demande d’agir rapidement car la DGFIP le menace d’une amende de 10%. Il faut valider manuellement le mandat sinon nous perdons notre bien aimé client ». Merci gus pour la traduction.
Ces simplifications importantes qui sont à mettre en œuvre dans les mois à venir impactent tous les SI – banque et client – sur les traitements, référentiels, contrôles, alertes et j’en passe. De même pour les processus dans les back et middle office.
Vers l’univers infini
Une fois ces simplifications en place, les moyens de paiements entrerons dans une phase de maturité : SI maitrisé, actions humaines réduites aux cas les plus critiques, rapidité d’exécution, fiabilité des traitements, sécurité des transactions.
L’idée séduisante est désormais partagée par l’ensemble des pays européens, y compris la Suisse, le Lichtenstein, ou San Marin. Après une mise en œuvre plutôt laborieuse, les européens ont mis en place un nouveau système de paiement global d’une puissance inégalée. Dès demain, toute personne (physique ou morale) de l’espace SEPA pourra toucher n’importe quelle autre personne dans des délais réduits et de manière sécurisée et simplifiée.
En fait, la mise en place de SEPA avait une double ambition.
Mettre en place des outils de paiements performants et standards en Europe, objectif en cours de finalisation. Mais également permettre l’éclosion de nouveaux services de paiement à haute valeur ajoutée.
Imaginez donc le résultat : avec SEPA, n’importe quelle entreprise a accès à un marché de plus de 740 millions d’habitants en une journée via un virement ou un prélèvement.
Demain, grâce à SEPA, les entrepreneurs qui développeront de nouveaux produits pourront directement assurer ce développement sur un marché dont le volume est supérieur au marché nord-américain et comparable à l’Inde.
SEPA va permettre l’éclosion de nouveaux modèles de paiements. Longtemps, les vecteurs d’échanges utilisés étaient normés et standardisés : le chèque, la carte, la demande de virement, le TIP… Demain, en utilisant les canaux de SEPA, n’importe quel « évènement » pourra déclencher un SCT ou un SDD. Utiliser un objet connecté, passer sous une arche, montrer son visage, lire une plaque d’immatriculation…
Bref avec SEPA, l’idée séduisante de départ permet à tout un secteur de passer d’un monde clos à un univers infini.
L’Architecture d’Entreprise est souvent vue de manière négative par les projets : effort coûteux, dé-corrélé de leurs contraintes, etc. Pourtant « sur le papier » cette pratique est très ambitieuse et prometteuse. Examinons les conditions d’un recours efficace à l’Architecture d’Entreprise.
Management de projets : tout change, rien ne change
Dans mon parcours professionnel, j’ai croisé et continue de croiser des « maîtres » qui influencent mes approches et mes convictions. L’un d’entre eux disait « le coût de la correction d’une erreur de conception est multiplié par 10 à chaque fois que l’on franchit une étape dans un projet : 1 au moment du cadrage, 10 en conception, 100 en réalisation / test, 1000 après le déploiement (lorsque c’est une fonctionnalité inadaptée qui a été déployée auprès de centaines d’utilisateurs) ». C’était à la fin des années 1990, et on était encore à l’époque sous le règne (finissant) de la méthode Merise.
Depuis, les technologies, la culture de projet et les compétences en ingénierie informatique se sont développées. Il existe aujourd’hui un grand nombre de « briques technologiques » utilisables pour assembler un SI comme un lego, sans avoir à développer spécifiquement chacune des pièces.
Cependant, rares sont les projets qui échappent aujourd’hui encore aux difficultés d’hier. On constate toujours une série de « manques » : manque de vision, de temps, de moyens, de savoir-faire, de discipline, de dialogue, d’analyse des besoins, etc. Plus que jamais, l’adage de mes débuts continue de se vérifier. D’ailleurs l’existence de « briques technologiques » de plus en plus élaborées, ne résout pas le problème d’architecture globale. En effet, on peut construire un truc très moche avec des lego très beaux !
Architecture d’Entreprise : l’art de traiter la complexité
Parmi les pratiques qui permettent de concevoir un SI, l’Architecture d’Entreprise est aujourd’hui celle qui apporte le maximum de garantie. Elle préconise l’extension des pratiques d’architecture du SI à l’ensemble des dimensions de l’entreprise. L’objectif poursuivi est d’éviter de ne penser l’architecture qu’en termes « d’architecture de solution informatique », qui est une réflexion trop restrictive car elle réduit le questionnement à la problématique informatique.
Pour compenser cela, les DSI font parfois intervenir sur les projets des maîtres d’ouvrage connaissant les applications, afin de conjuguer réflexion sur le métier et réflexion sur la solution. Cependant cela détourne souvent le maître d’ouvrage de son rôle : étudier l’opportunité et cadrer les besoins. Il arrive encore qu’on démarre des projets sans savoir s’ils sont vraiment souhaitables et faisables, avec pour seul actif une liste de besoins.
L’Architecture d’Entreprise propose un cadre permettant d’assurer une continuité d’analyse entre les différentes phases du projet. Elle couvre aussi l’analyse d’opportunité en amont des projets. Mais alors pourquoi les problèmes ne sont-ils pas déjà résolus ? Sans doute la démarche est-elle perçue comme complexe à déployer et à s’approprier (c’est l’argument le plus souvent entendu). En effet, le déploiement d’une démarche Architecture d’Enterprise appelle une évolution de l’organisation des démarches d’étude et de projet. Elle doit être portée par une ambition managériale et par la mobilisation des équipes. A défaut on verse immédiatement du côté obscur et l’on ne retient de l’approche que ce qu’elle a de plus hermétique : la méthode … inconcevable quand on manque de temps, manque de moyens, manque de savoir-faire, manque de discipline, manque de dialogue, etc. On finit par oublier le parti qu’on pourrait tirer de cette réflexion pour l’analyse.
Ce n’est pas le marteau qui fait bouger la main, mais l’inverse
Quand cet outil d’analyse est utilisé correctement, de manière pragmatique, on en voit immédiatement la valeur-ajoutée pour les projets. Et ce, sans attendre le déploiement des applications et le verdict des utilisateurs.
Lorsque l’Architecture d’Entreprise est présente dès le point d’ignition du projet (ou avec bonheur, plus en amont encore : lors d’un schéma directeur) elle est à même de porter et fédérer toutes les dimensions de l’analyse et répondre aux attentes des acteurs de la transformation :
Comprendre les enjeux des projets, et leur intérêt par rapport à la stratégie métier, pour donner des perspectives aux projets
Identifier conjointement les impacts pour le métier et la DSI, en animant le dialogue bipartite métier/IT qui soutient la transformation
Pouvoir identifier les ressources et les capacités d’évolution qu’il faudra mobiliser, et vérifier qu’elles sont bien disponibles (à quoi servirait une cible, sans la capacité d’évolution pour l’atteindre ?)
Donner aux équipes concernées les repères communs et partagés qui sont nécessaires pour fédérer les visions personnelles (forcément partielles et partiales)
Livrer les premiers plans ré-exploitables de la cible sous forme de schémas non équivoques, ainsi que des trajectoires appropriées pour l’atteindre
Créer la mobilisation autour du projet en propageant les nouvelles représentations mentales qu’implique la cible
(liste non exhaustive)
En résumé, l’Architecture d’Entreprise fait exister le projet avant qu’il n’existe. Puis elle l’accompagne dans son cycle de vie vers sa réalisation (son accomplissement !). Disposer d’un plan de route pour conduire une transformation est tellement utile lorsque les projets sont stratégiques, transverses et complexes. Faisons-le savoir, comme monsieur Jourdain pour la prose, l’architecte d’entreprise fait du management, sans qu’on le sache ! Mais lui, il le sait.
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.
