Le deuxième Petit-Déj’SI

Praxademia a convié quelques décideurs informatiques à échanger autour d’un petit-déjeuner, tenu au Pavillon Ledoyen, le 15 octobre 2015.

Le compte rendu est publié via le groupe Praxeme sous LinkedIn.

Ci-dessous, l’ordre du jour indicatif établi par Joël Bizingre (Conix Consulting) et Dominique Vauquier.

L'ordre du jour du Petit-Déj'SI

Voir aussi :

 

Le positionnement de l’architecture d’entreprise par rapport aux autres disciplines

Comment se positionne l’architecture d’entreprise par rapport aux disciplines transformationnelles[1] ?

La figure ci-dessous tente une première mise en ordre. Le niveau supérieur représente celui des considérations globales, s’appliquant à l’ensemble de l’entreprise. Il s’agit, de plus en plus, d’une fédération d’entreprises, composée de nombreuses entreprises liées par des relations capitalistiques, juridiques, commerciales ou partenariales. À cet étage, un concept pivot est celui de la chaîne de valeur étendue.

Le paysage des disciplines de la transformation (en théorie)

Le paysage des disciplines de la transformation (en théorie)

Conformément à la définition donnée dans l’Enterprise Transformation Manifesto[1], l’architecture d’entreprise se situe à ce niveau, du moins si elle reste fidèle à sa première inspiration.

Stratégie et architecture : une collaboration nécessaire

À ce niveau, l’architecture d’entreprise cohabite avec l’élaboration de la stratégie d’entreprise : non seulement elle reprend les orientations stratégiques pour en déduire les implications, dans tous les aspects de l’entreprise, mais encore elle informe la stratégie sur les opportunités ou les contraintes relatives à l’entreprise ou à son environnement. On pense, bien sûr, aux innovations technologiques à domestiquer pour les mettre au service de l’entreprise. D’autres opportunités peuvent se présenter : innovation organisationnelle, style de management, reconception de l’offre, extension de la chaîne de valeur, etc. Le stratège n’est pas forcément sensible à toutes ces questions. Son regard est surtout tourné vers l’extérieur, le marché, la concurrence… Son horizon est le moyen terme (disons trois ans), voire le court terme (avec les « stratégies glissantes »). Au contraire, l’architecte connaît l’entreprise, il la modélise et la traite comme un système, avec ses finalités, ses propriétés émergentes, ses contraintes et ses possibilités d’adaptation ; il est très conscient de l’inertie de ce paquebot et sensible à la longue durée dans laquelle la transformation doit se déployer. Le dialogue doit impérativement s’établir entre ces deux compétences tout à fait complémentaires :

  • Le stratège donne la direction ; l’architecture en déduit l’esquisse du Système Entreprise à construire.
  • L’architecture identifie le potentiel de transformation ; le stratège cherche à l’employer dans le contexte du marché.

Management stratégique : le discours directionnel

Toujours au niveau de l’entreprise, l’architecture d’entreprise voisine avec le management. Tout naturellement, la relation devrait s’établir avec le management stratégique (disons le PDG), seul capable d’affirmer la vision, d’affermir les volontés et d’impulser la transformation. Qu’est l’architecte sans le prince ? On peut mobiliser Le Brun, Le Nôtre, Le Vau ; sans Louis XIV, il n’y a pas de château de Versailles.

L’architecte apporte le savoir, précise la vision et fournit les plans ; mais la volonté reste dans le management.

Il y a quelque chose d’un peu pitoyable (au sens premier du terme : qui inspire la pitié), à considérer le patron réitérant ses injonctions à innover, ses incantations sur la convergence ou l’orientation client (ou la simplification administrative), sans se montrer capable de remplir le concept. Très vite, dans l’esprit de tous, les formules se vident de substance et il ne reste que des slogans creux. Nul ne saurait reprocher au dirigeant cette situation : le « remplissement du concept » (pour reprendre une formule heideggérienne) n’est pas de son ressort. Mieux vaut voir dans cette situation une défaillance de la courroie de transmission vers les compétences dont c’est le rôle : justement celles de la conception architecturale dans toutes ses spécialités. Or, puisque l’architecture d’entreprise s’est confondue avec l’architecture informatique[2], il ne vient à l’idée de personne qu’elle puisse intervenir pour relayer le discours directionnel – précisément : le discours de la direction et le discours qui donne la direction. Pourtant, quand cette discipline se montre capable de réaliser ses potentialités à travers un exercice correct, elle étaye le discours et précise la vision en décrivant concrètement la cible à atteindre, l’entreprise future à construire.

Management opérationnel : la culture de l’entreprise « transopérationnelle »

Sur ce schéma, le management est positionné à cheval entre la transformation et les opérations. On vise ici le management opérationnel. En effet, l’idée va plus loin que le classique jeu de rôle entre le DG – pilotant les opérations – et le PDG – s’occupant de la vision de l’entreprise future (donc, de la transformation). Dans l’entreprise moderne, un nouvel équilibre doit s’instaurer entre transformation et opérations. Ces activités doivent se mêler plus intimement dans l’entreprise « transopérationnelle », pour que celle-ci s’adapte en permanence et rapidement à un environnement changeant. Ce nouvel alliage seul pourra rendre l’entreprise réellement agile.

Ainsi, même les managers opérationnels et tout le middle-management doivent avoir un pied dans la transformation. À eux de détecter les dysfonctionnements et les opportunités d’amélioration. Ceci suppose une conversion culturelle et une éducation qui contredira les tendances naturelles.

La ligne hiérarchique doit repenser son rôle et ses pratiques, se débarrasser de ses mœurs courtisanes et se penser comme le canal assurant la diffusion accélérée des idées innovantes et des initiatives de transformation, dans les deux sens.

Aujourd’hui, le constat que tout le monde partage, chacun l’exprimant dans ses propres termes, est celui d’un système bloqué, dévoyé :

  • en bas, dans la soute, des opérationnels persuadés qu’ils ne seront pas écoutés et qui ont perdu, de ce fait, la faculté de reconnaître les bonnes idées, quand elles se présentent ;
  • au sommet, des dirigeants qui font la danse de la pluie, qui assurent la représentation, mais qui se sentent impuissants à peser réellement sur le cours des choses.

Cet état s’observe, tant dans la société que dans les organisations. On pourrait y voir un état de civilisation. L’un accuse les jeux de pouvoir, un autre le court-termisme, un troisième l’influence du capital ou de la taille des empires créés par la mondialisation, etc. Les facteurs sont nombreux ; la prise de conscience, étonnamment répandue. Il ne faudrait pas omettre un autre élément, de nature plus psychologique : l’individu, coincé dans sa case, finit par la trouver confortable, il renonce assez facilement à ses velléités d’action, et ne demande qu’à échapper à ses responsabilités. Pour cela, le blocage du système lui fournit un alibi bien commode (voir, par exemple, ce que dit François Dupuy sur les silos. Cf. Lost in management).

Cette logique délétère qui bloque l’entreprise, on n’y échappera qu’en s’appuyant sur le management opérationnel et en l’impliquant fortement dans la transformation. Ceci réclame un choc culturel – électrochoc sur un monstre assoupi.

Architecture métier : le premier moment de l’architecture d’entreprise

Sur la figure, le niveau suivant concerne toujours l’entreprise prise globalement, mais il introduit une séparation entre, d’un côté, le « métier » et, de l’autre, la technique. Cette spécialisation répond à la prise en compte réaliste des limitations humaines : on ne peut pas mettre toutes les compétences dans un même cerveau. L’architecture métier, comme toute architecture, adopte un point de vue global sur le système et assume les préoccupations sur la longue durée. Elle le fait sur une partie seulement des aspects du Système Entreprise :

  • l’aspect intentionnel (les valeurs, les objectifs, les exigences, les indicateurs, les règles, la terminologie) ;
  • l’aspect sémantique (la connaissance, les fondamentaux du métier) ;
  • l’aspect pragmatique (les activités et l’organisation).

Disciplines techniques

Les aspects techniques sont laissés à d’autres disciplines, telles que l’architecture informatique. On distingue :

  • l’architecture logique, élaborant la structure souhaitée pour le système technique (informatique comprise) ;
  • l’architecture technique, explorant les possibilités technologiques et les combinant pour traduire la spécification logique en un système qui fonctionne ;
  • l’architecture physique qui s’intéresse à l’infrastructure, au déploiement et à l’exécution des moyens techniques.

Architecture et conception

Le troisième niveau de la figure correspond aux disciplines de portée locale, c’est-à-dire, presque toujours, celles qui s’investissent en mode projet. L’architecture est là pour canaliser cette énergie, de façon à avancer plus rationnellement et plus rapidement dans la construction du système. À ce niveau, du côté du métier, se situe la Business Analysis, discipline bien constituée qui dispose de ses instances représentatives et de son référentiel. Toujours par fidélité naïve à la langue, on peut se demander pourquoi il n’existe pas une discipline Business Design, pendant créatif de la Business Analysis. Cette absence entraîne des conséquences : la faible capacité à innover dans le métier.

Du côté technique, l’arbre des disciplines se ramifie bien plus, du fait de la complexité des sujets et de la variété des expertises.

Architecture d’entreprise : par voie de conséquence

Après ce petit essai de mise en ordre des disciplines, l’architecture d’entreprise apparaît sous un jour nouveau. Nous la découvrons comme le lieu où tout converge. Plutôt qu’une spécialité pointue investissant tel ou tel aspect, elle est la capacité à concilier les différents points de vue et à garantir l’unité de la vision. Elle doit tenir, d’une même main, les rênes des disciplines de conception du Système Entreprise. Elle doit guider l’attelage, dans la direction fixée par le stratège. Sa responsabilité consiste à assurer la cohérence du projet de transformation.

Sans cette fonction, beaucoup d’énergie et de talents seront gaspillés ; beaucoup d’opportunités manquées.

L’architecture d’entreprise doit assurer la circulation des idées, en mettant en œuvre une approche holistique de l’entreprise.

Évidemment – l’expérience le montre assez –, la position centrale, de surplomb, présente des risques, dont celui de la tour d’ivoire. Il importe que le travail d’architecture d’entreprise ne s’arrête pas à quelques généralités, assorties de vagues schémas ou de présentations simplistes et démagogiques. Le mot « architecture » doit être pris dans son sens fort : le travail commence par une esquisse, certes, mais à la fin, le bâtiment doit tenir debout et se prêter à tous les usages prévus. On ne peut atteindre cet objectif qu’avec le secours des techniques de modélisation, car elles apportent le niveau de précision nécessaire ainsi que les règles formelles par lesquelles l’architecte peut vérifier la validité de sa conception. Avant cela, le premier instrument est le cadre de représentation : il donne la topologie de l’entreprise, nécessaire pour ordonner les sujets à traiter et pour distribuer les responsabilités, toutes disciplines confondues.

Article en format pdf : PositionnementEA

[1] Cf. www.enterprisetransformationmanifesto.org.

[2] Voir le billet « Le PDG est le premier client de l’architecture d’entreprise…(en théorie) » sur LinkedIn ou sa version étendue « Comment promouvoir une démarche d’architecture d’entreprise ? », sur le site web de Praxademia.

[1] Nous nommons « transformationnelles » les disciplines impliquées dans la transformation des entreprises.

Comment promouvoir une démarche d’architecture d’entreprise ?

Comment promouvoir une démarche d’architecture d’entreprise ?

La question a été posée par les décideurs informatiques réunis à l’occasion du Petit-Déj’SI®, au mois de mai. Elle a été retenue comme thème de la prochaine séance qui se tiendra le 15 octobre.

Le fait que la question se pose et qu’elle soit posée par des décideurs informatiques révèle déjà beaucoup de choses :

  • tout d’abord, que la discipline d’architecture d’entreprise est interprétée comme ressortissant à la fonction informatique ;
  • ensuite, que sa valeur ne semble pas immédiatement perçue par le reste de l’entreprise (sans doute une conséquence du premier point) ;
  • enfin, qu’il s’agirait de faire un effort – de communication, j’imagine – pour la légitimer, la vendre, la justifier aux yeux du monde.

En tout premier lieu, il convient de préciser de quoi nous parlons. Qu’est-ce que l’architecture d’entreprise ? Je suis désolé de revenir sur cette question que l’on voit fleurir chaque mois sur les forums et qui déclenche, à chaque fois, une avalanche de réactions. Néanmoins, nous ne pourrons pas répondre à la question posée avant d’avoir clarifié son concept central. Pour définir un tel objet, nous devrons d’abord en retrouver l’inspiration originelle, puis le positionner par rapport aux autres disciplines. Armés de la définition, nous pourrons reprendre la question.

L’architecture d’entreprise, en théorie

Personnellement, j’aurais tendance à faire confiance au langage (plus qu’aux Hommes, et tant que les Hommes n’auront pas trop abîmé le langage). Dans l’expression « architecture d’entreprise », il me semble reconnaître le mot « entreprise ». S’il s’agit d’une discipline, son objet doit donc être l’entreprise, dans son entier. Certes, le besoin est patent d’une discipline qui soit capable d’embrasser toutes les composantes de l’entreprise, tous ses aspects, afin de les articuler et de faire circuler les idées entre les silos d’expertise. Ce qui est en jeu n’est rien moins que la capacité à innover et à transformer l’entreprise.

Ensuite, nous avons le mot « architecture ». Bien sûr, il apparaît ici dans un usage métaphorique. La métaphore de l’architecture n’est pas nouvelle : nous la convoquons à chaque fois que nous voulons mettre en avant la maîtrise et la conception consciente de la structure. Elle a cours, depuis toujours, dans le milieu de l’informatique. Elle y prolifère même : architecture matérielle, architecture logique, fonctionnelle, applicative, logicielle… architecture d’un compilateur, etc. Une vache y perdrait son veau, et un curé son latin ! (NB : il y a beaucoup de grec, là-dedans)

Faisons simple :

L’architecture d’entreprise est la discipline qui prend l’entreprise comme un tout, et qui élabore, consciemment, consciencieusement, sa structure.

L’architecture d’une entreprise en est le résultat. Ne confondons pas le livrable « dossier d’architecture de l’entreprise » avec ce résultat : l’entreprise même, construite, transformée, régénérée, selon la structure qui a été conçue et qui devient sienne. Les plans de l’architecte ne sont pas le bâtiment (la carte n’est pas le territoire, ceci n’est pas une pipe, les médias ne sont pas le monde, etc.). En tout cas, l’analyse de l’expression nous conduit à cette conclusion : l’architecte d’entreprise s’occupe… de l’entreprise !

L’architecture d’entreprise, en pratique

Qu’en est-il en réalité ? Qui se parfume de ce beau titre d’architecte d’entreprise ? Quelle est sa formation ? sa position dans l’organigramme ? sa pratique ?

Il est facile de répondre à ces questions puisqu’une puissante machine de guerre a été mise en place sous la bannière de l’Enterprise Architecture. J’ai nommé : l’Open Group et la certification TOGAF (The Open Group Architecture Framework). On nous dit que quelque 38.000 architectes sont certifiés TOGAF à travers le monde, ceci sans compter les personnes qui ont obtenu leur certificat à partir de versions antérieures, ni celles qui, sans être certifiées, sont fortement exposées au sujet ou y font constamment référence. Même les administrations françaises sont touchées par le phénomène ; on les avait connues plus résistantes à la culture méthodologique américaine.

Donc, la population des « architectes d’entreprise » est facile à identifier, d’autant qu’elle ne manque pas de dispositifs pour s’exprimer : un réseau d’associations dans tous les pays, des centaines de forums dans toutes les langues.

Où les trouve-t-on ? Réponse : sans exception aucune, dans les directions informatiques. Est-ce la meilleure position pour aborder tous les aspects de l’entreprise ? Est-ce que la pratique informatique prédispose à la transformation et à l’ouverture sur les réalités de l’entreprise ?

Concédons que l’on peut se trouver à un endroit de l’organisation et agir ailleurs. Est-ce le cas de l’architecte d’entreprise ? Pas sûr. Nous pouvons aventurer ce constat : l’architecture d’entreprise, en pratique, est l’architecture informatique à l’échelle de l’entreprise. Encore est-ce là le meilleur des cas. Le plus souvent, la dimension « entreprise » n’y est pas. Il n’est, pour s’en convaincre, que de jeter un œil sur les offres de postes. Elles recensent des compétences et connaissances informatiques, voire strictement techniques, et font fi des autres aspects de l’entreprise. Elles décrivent, le plus souvent, une fonction d’expert technique plutôt que d’architecte technique : la maîtrise d’une technique, pas la capacité à assembler plusieurs techniques pour concevoir un système technique.

Pourquoi, alors, ne pas se contenter de parler d’architecture informatique ? Les raisons sont multiples et nous ne les examinerons pas ici (il faudrait aborder l’histoire des termes, le glissement sémantique constant, les stratégies des acteurs, etc.). L’expression « architecte d’entreprise » s’est simplement substituée à celle d’« architecte informatique ». De même, on n’entend plus parler que du « système d’information » et quasiment plus du « système informatique ».

Il est toujours plus facile de changer les termes que les pratiques.

Quand il s’agit des dénominations professionnelles, c’est pire : dans la foire aux vanités, les titres tournent, ronflent et se galvaudent à une vitesse accélérée.

Ces manipulations langagières ne seraient pas si graves si leurs effets se cantonnaient aux éternels et minables calculs d’intérêt et luttes corporatistes. Mais ce phénomène d’érosion sémantique met en danger le langage, comme outil de représentation et de communication. Parfois, il menace l’avenir des concepts. C’est tout à fait le cas avec l’architecture d’entreprise. Qui aperçoit encore, sous cette appellation, le concept décrit ci-dessus ? Certes pas les dirigeants. En effet, tentons un rapide sondage : demandons aux dirigeants ce que leur évoque l’expression « architecture d’entreprise ». Combien imagineront que cela puisse être autre chose que de l’informatique ? Lesquels, parmi eux, se diront que cela les concerne ? Alors que, justement, le concept initial est une réponse à la situation d’urgence des entreprises et un puissant levier pour leur transformation.

Les entreprises réclament – de toute urgence – une approche holistique, sans laquelle la transformation n’est qu’un vain mot, un songe creux.

Les dirigeants en sont les premiers demandeurs. L’architecture d’entreprise, prise au sens fort, répond justement à cette attente. Comment donc la nommer, maintenant que l’expression « architecture d’entreprise » a été saccagée ?

Faute de mieux, nous continuerons à utiliser cette expression, en l’entendant dans son sens fort. L’ Enterprise Transformation Manifesto repose entièrement sur cette notion et cherche à déployer son ambition et à illustrer son potentiel, dans les termes des décideurs : transformation, valeurs, politique, innovation, responsabilité… Il n’omet pas la technologie, dont l’importance dans la transformation ne saurait être minorée, mais il l’associe aux autres contributions nécessaires pour élaborer une vision complète.

Synopsis of the Enterprise Transformation Manifesto

Synopsis of the Enterprise Transformation Manifesto

En conclusion, j’adopte cette définition, due à Thierry Biard :

« L’Architecture d’Entreprise permet de concevoir, du métier à la technique, l’Entreprise dans tous ses aspects. »

Le terme « aspect » a, ici, un sens très fort. Il renvoie au cadre de représentation proposé par Praxeme, la Topologie du Système Entreprise.

Article plus complet : PromouvoirDemarcheAE (pdf)

Quelques éclaircissements sur le chantier Praxeme

Méthodologie d’entreprise

Dès l’origine, Praxeme s’est voulue comme une méthodologie d’entreprise, c’est-à-dire une réponse au besoin patent que rencontrent les entreprises et que perçoivent les dirigeants : articuler les expertises, les mettre en synergie. Conséquence : l’expression “Enterprise Architecture” (EA) a été prise au pied de la lettre, comme désignant une discipline qui pense l’entreprise comme un tout, dans toutes ses dimensions. Dès lors, Praxeme se sépare des méthodes proposées sous l’étiquette EA et qui sont toutes dans la sphère de l’informatique. Zachman, avec son questionnaire du Quintilien et son approche matricielle, aurait pu couvrir l’entreprise, mais sa façon de répondre (What = Data) lui a fait manquer la cible. On ne peut pas lui en vouloir : les déterminations historiques et culturelles ne pouvaient pas produire, à l’époque, un autre résultat.

Par rapport à l’architecture d’entreprise

Donc, Praxeme n’est pas une méthode d’architecture, fût-elle d’entreprise. Si nous disons “méthodologie d’entreprise” ou “méthodologie de transformation d’entreprise”, c’est pour affirmer l’ambition de créer le creuset dans lequel toutes les approches de l’entreprise viendront converger et se fondre en un nouvel alliage. Le sujet est donc, en premier lieu, d’identifier les multiples rationalités qui traversent l’entreprise et de les amener à se reconnaître et à mieux cohabiter. Pour cela, il est besoin d’adopter une posture de méta-rationalité (non d’hyper-rationalité, car elle a bien conscience de la rationalité limitée, ce qui la teinte de modestie). Bien sûr, une méthodologie d’entreprise ménage sa place à l’architecture d’entreprise, discipline clef dans la transformation de l’entreprise (au même titre que la conception stratégique, l’organisation et bien d’autres disciplines).

Ces deux points, combinés, obligent à repenser les fondations et même à rechercher un autre sol pour fonder le nouvel édifice. Certes, la tradition informatique joue un rôle non négligeable dans cette perspective, non seulement du fait de nos trajectoires individuelles (ce serait un peu mesquin) mais surtout par la nature même de l’informatique, intermédiaire obligé entre le réel et l’idéel. (Je ne m’étends pas ; je me contenterai de renvoyer au maître ouvrage de Pierre Lévy, La machine univers.)

C’est ainsi qu’il est apparu nécessaire d’identifier les règles pour construire le cadre de référence, la grille de lecture à appliquer à l’entreprise. De là, la nouvelle version de la Topologie du Système Entreprise. Un chiffre pour juger de notre recherche : la version 1 de la TSE comptait 8 aspects dont 4 liés à l’informatique ; la version 2 n’en compte plus que 7, l’informatique étant une des composantes de deux des aspects. Le document PxPRD-01, inscrit au catalogue de la version 2, présentera ces règles et le résultat de leur application. Ce sujet a été présenté dans la formation exceptionnelle “Business Architecture & Transformation“.

Rapprochement entre référentiels de pratiques

Mieux intégrer l’EA avec des référentiels de pratiques comme ITIL ou COBIT va évidemment dans le bon sens, d’autant que ces référentiels ont tendance eux-mêmes à élargir leur domaine et à élever leurs aspirations. Mais pourquoi se limiter aux pratiques informatiques ? N’est-il pas aussi important, pour réussir son architecture d’entreprise, de la coupler à la conception des processus, donc à l’organisation, ou à la modélisation éthique et à la stratégie comme discipline ? Ces domaines s’appuient aussi sur des référentiels ou, du moins, sur une littérature abondante et une tradition riche. Il faudra bien réussir la connexion, sauf à rester confiner dans le champ de l’IT et à amputer notre capacité d’innover.

A propos d’agilité

En ce qui concerne l’agilité, nous sommes face à une contradiction. C’est surtout la contradiction d’essence entre le mode projet (portée locale et à court terme) et la portée système (vision long terme et globalisante de l’architecture). La nécessité de concilier stabilité et agilité de l’entreprise amène à penser le rapport entre :

  • agilité des activités de transformation, d’une part,
  • qualité de l’architecture, d’autre part.

La proposition de Praxeme pour résoudre l’équation consiste à réorganiser les activités de transformation, architecture et projet compris, autour du Référentiel de description de l’entreprise. Ce pot commun n’est, certes, pas facile à construire et il y faut une gouvernance subtile et décidée. Mais, quand il existe, c’est le moyen de gagner sur les deux tableaux : préserver la puissance et l’ambition de la vision architecturale, d’un côté, et accélérer les projets en les guidant vers l’intérêt commun, de l’autre. Ici nous touchons à la complexité de l’entreprise, complexité qui tient, en grande partie, à sa substance mélangée. C’est justement le rôle de la méthode d’analyser la nature de ce matériau, d’en séparer les éléments pour créer les conditions opératoires. La propagande sur les projets agiles, seule, ne peut pas suffire ; le platonisme de l’architecture idéale (top-down…), seul, ne mène nulle part. Il faut combiner les deux.

En résumé

“Refonder l’architecture d’entreprise” : c’est, je crois, ce que nous avons fait ou plutôt, c’est la conséquence presque involontaire de notre approche holistique de l’entreprise : voulant embrasser toute la réalité de l’entreprise et ordonner toutes les informations et les décisions qui la concernent, nous rencontrons, sur notre chemin, les disciplines et nous leurs assignons des responsabilités dans la perspective plus vaste de la transformation.
“Assembler les pratique” : Praxeme s’est toujours présentée comme une approche interdisciplinaire, un cadre pour coordonner les différentes pratiques et un vecteur pour amener les apports scientifiques et les mettre au service de l’entreprise.
Sur l’agilité : le grand sujet n’est pas l’agilité des projets. Au début de années 80, James Martin avait déjà dit l’essentiel avec sa méthode RAD trop rapidement interprétée comme l’autorisation de jeter les modèles par dessus bord. Il faudrait un jour qu’un économiste chiffre le désastre économique qui s’en est suivi. Le grand sujet est l’agilité de l’entreprise, laquelle réclame justement un gros effort d’architecture et une approche rigoureuse.