La formation certifiante “Compétences Praxeme”

Praxademia assure la formation “Compétences Praxeme”, sous mandat exclusif du Praxeme Institute

PxSkillsAgendaVisuel

Il s’agit d’un panorama complet de la méthodologie d’entreprise.

Les trois journées intensives se concluent par un examen certifiant, permettant d’obtenir le certificat “Fondations”.

 

Voir la description de la formation et les modalités d’inscription.

 

Au-delà du certification “Fondations”, le Praxeme Institute a arrêté une architecture de la certification, visant à couvrir tout l’éventail des compétences à mobiliser dans les programmes de transformation. Voir le schéma de la qualification.

Prochaine session : voir le calendrier

 

La donnée : du sens au code

La présentation commentée de la conférence “La donnée : du sens au code”, donnée par Dominique Vauquier lors du Symposium Praxeme 2015, est disponible sur le site du Praxeme Institute : http://wiki.praxeme.org/index.php?n=Syllabus.SYE03.

L’ensemble des matériaux utilisés lors du Symposium, notamment pour la conférence de Joël Bizingre sur les big data et celle de Fabien Villard sur l’estimation des charges, se trouve rassemblé sur la page : http://wiki.praxeme.org/index.php?n=News.Symposium2014.

Big data : la nécessaire sémantisation des données

En exploitant les nouvelles sources de données, à un moment ou à un autre, se pose la question de la signification de ces données. Également, pour tirer un plus grand profit de la connaissance acquise, la donnée doit être rapportée à un concept, c’est-à-dire à l’objet (physique ou abstrait) qui la porte. Elle doit s’articuler aux autres facettes de cet objet.
C’est le rôle de la modélisation sémantique de dégager la signification des données, de les formaliser en tant que propriétés du concept et de les inscrire dans une structure manipulable.

La modélisation sémantique apparaît donc comme un outil incontournable pour bénéficier des techniques X-data. En retour, les X-data influent sur la modélisation sémantique – sinon sur ses procédés, du moins sur son contenu. Notamment :

  • assimilation de nouvelles propriétés dans le modèle sémantique (complétant les classes sémantiques, déjà identifiées, avec des “détails” issus des big data), particulièrement des propriétés de portée classe (valeurs agrégées, indicateurs issus des open data),
  • extension du modèle à des notions nouvelles (par exemple, meilleure description des objets appartenant à l’environnement de l’entreprise, les personnes, leurs relations, leurs comportements, les événements externes…),
  • évolution vers un “style” de modèle qui ménage leur place aux comportements, aux corrélations et aux anticipations (des catégories de propriétés que l’on peut considérer comme nouvelles ou, en tout cas, d’usage rare dans la modélisation classique), avec un enrichissement conséquent des automates à états et de la propagation des changements d’états.

Praxeme exhorte le modélisateur à ne pas réduire la connaissance du métier à celle des données. Le choix du terme “sémantique” en lieu et place de “conceptuel” découle de cette position, ce dernier terme évoquant fortement le modèle conceptuel des données alors que le modèle sémantique prend en charge le concept, tout le concept, sous ses trois facettes réconciliées dans l’unité de la classe : information, action, transformation.

Un modèle de données n’est pas un modèle sémantique

On change plus facilement les appellations que les pratiques. Aujourd’hui, il est de bon ton d’insister sur les objets métier. C’est une très bonne chose… à condition d’en faire des modèles qui ne soient pas que des modèles de données “à l’ancienne”. Je réponds ci-dessous à une question qui m’a été posée sur ce que change l’utilisation d’UML par rapport à Merise.

Qu’est-ce qui fait, fondamentalement, que les entités de Merise sont distinctes de ce que l’on nomme “objets métier” ? En dehors de la notion d’héritage (et donc de spécialisation dans UML), qu’est-ce qui fait, dans le formalisme et dans les principes, qu’UML est plus adapté que Merise pour représenter les objets métier ? Est-ce-qu’en pratique, ce sont les notions d’agrégation et de composition qui changent tout ?

 

Tout d’abord, Merise – méthode de conception informatique – ne nous enseigne pas à représenter la connaissance métier mais impose, dès l’abord, la séparation données-traitements. Le MCD est un modèle de données : c’est dire qu’il ne peut pas représenter toute la connaissance des fondamentaux du métier. Conséquence pratique : certaines informations ne peuvent pas être inscrites sur le modèle, sous prétexte qu’elles sont calculées (ex. l’âge de la personne alors que l’on a la date de naissance). C’est tout à fait justifié pour un modèle de données, ça ne l’est pas pour un modèle sémantique. Du point de vue de l’acteur métier, ces distinctions entre données brutes et données calculées n’ont pas cours : il voit des informations qui font partie du concept.

Plus important encore : la sémantique d’un concept ou d’un objet métier ne s’arrête pas aux propriétés informatives : elle comporte également des propriétés actives (ce que l’objet peut “faire”) et des propriétés transformatives (comment il se comporte ?). Si nous voulons exprimer toute la sémantique, nous devons associer à l’objet métier : les opérations et leurs conditions d’emploi, les contraintes (règles métier), les états (cycles de vie)… bref tout ce qui complique dangereusement nos solutions informatiques faute d’une approche appropriée.

Si la notation UML est bien utilisée, elle peut outiller la modélisation sémantique. Les classes portent les trois types de propriétés : informatives (sous la forme d’attributs, y compris attributs calculés et attributs de portée classe) ; actives (les opérations) ; transformatives (les contraintes et les automates à états).

Évidemment UML est connotée “logiciel” (et est, d’ailleurs, largement sous-exploitée par les informaticiens dont les pratiques de modélisation ont considérablement régressé au cours de ces dernières décennies). Mais il ne faut pas oublier que les notions et axiomes qui forment la logique objet proviennent de la philosophie de la connaissance (de là le terme “classe”) : ce n’est donc pas un hasard si cette logique et les notations qui l’expriment se prêtent aussi facilement à la représentation des connaissances. A noter aussi que l’élargissement des possibilités de modélisation (dans un modèle sémantique par rapport à un MCD) n’aboutit pas à un simple ajout de propriétés sur le modèle : il en change la structure. Ce que je veux dire par là, ce n’est pas seulement les éléments visibles qu’apporte UML par exemple (héritage, agrégation…) : ces éléments pouvaient être, en partie, restitués dans l’approche classique. C’est qu’en prenant en compte toutes les propriétés des objets métier et en suivant les exigences de généricité et de factorisation, le modélisateur est conduit à arranger différemment l’ensemble des propriétés. Les conséquences de ces changements de structure sont énormes : si on les suit sur toute la chaîne de transformation (conception des processus, automatisation…) l’enjeu se chiffre en millions d’euros. L’exemple d’école est la notion de Personne (ou client, employé, etc.). En appliquant rigoureusement cette approche, on peut diviser le volume des SI par 2, facilement ! Tout en augmentant le confort d’utilisation parce que l’on aura construit des solutions plus proches des représentations naturelles.

En conclusion, un modèle sémantique est bien plus qu’un modèle conceptuel des données (il le contient et on peut, à tout moment, extraire le modèle des données d’un modèle sémantique. Praxeme propose plusieurs filières de dérivation à partir du modèle sémantique, dont celle qui produit le modèle logique des données).
L’appellation “Business Object Model” a servi un peu trop à désigner des MCD (et parfois, même pas bons : on en a de lamentables exemples sur le marché). Ce qu’on appelle un BOM (par exemple celui d’IBM) ou l’Information Model d’ACORD ne sont que des modèles de données (même pas normalisés). Les conséquences sont dramatiques. Mais c’est une autre histoire…

Ce commentaire ne remet pas en cause l’héritage de Merise. UML est une notation, pas une méthode. Merise est une méthode et beaucoup de ses recommandations non seulement restent d’d’actualité mais encore sont nettement supérieures à ce que l’on trouve dans les méthodes orientées objet et dans les pratiques courantes. Donc, nous avons tout intérêt à faire fructifier notre héritage. Praxeme reconnaît bien volontiers sa filiation avec Merise.

L’éthique en entreprise

Ces dernières années, nous avons vu fleurir les chartes et codes éthiques dans les entreprises et se généraliser la notion de responsabilité sociétale de l’entreprise.

Nous pouvons nous réjouir de ce phénomène, qui traduit bien plus que la prise de conscience du rôle et de la nature de l’entreprise : il montre aussi qu’à une époque où les idéologies ont reflué, les institutions normalement porteuses de sens et de morale ne suffisent plus pour produire et actualiser le discours de valeurs.

Cependant, est-ce si naturel, pour l’entreprise, de se mêler de morale ? N’y a-t-il pas des effets secondaires et des risques ?

En préparation au développement des procédés axiologiques (sur les valeurs) dans la méthodologie d’entreprise, un papier vient d’être publié par Dominique VAUQUIER sur le site du Praxeme Institute.

  • Constat : le discours sur les valeurs ; les risques et les enjeux ;
  • Problématique : la morale en entreprise ne va pas de soi ; elle se heurte au fait que l’individu y est considéré comme une ressource, en contradiction avec l’impératif catégorique qui veut que l’être humain doit toujours être considéré comme une fin en soi, jamais comme un moyen (Emmanuel Kant). C’est une bonne chose que l’éthique se développe au sein des entreprises, mais elle ne pourra jamais être sincère que si on affronte son caractère problématique.
  • Méthodologie : le papier présente les procédés “Élucider les valeurs”, “Négocier les valeurs” et la grille d’analyse des modèles éthiques.

Voir : page du site du Praxeme Institute.

Avertissement : ce document n’est pas un élément de la méthode, mais une réflexion préparatoire. Les procédés seront développés en fonction des contributions et des opportunités.

Méthodologie d’entreprise

Tout le monde en convient : l’entreprise est un objet complexe, tissé de multiples déterminations, obligé sans cesse de s’adapter à un monde changeant. Comment penser cette complexité ? Comment tout dire de l’entreprise sans risquer d’omettre un facteur décisif ? Comment trouver les bonnes idées qui vont assurer l’avenir ?

Il serait illusoire de croire qu’une formule unique, tel un charme magique, suffirait à appréhender cette réalité complexe. Nous devons convoquer de nombreuses disciplines et articuler des expertises variées. Pour les mettre en synergie, nous devons les couler dans un cadre interdisciplinaire, cohérent et capable de tirer parti de tous les apports. Cette exigence définit la méthodologie d’entreprise.

Praxeme est la méthodologie d’entreprise, issue de l’initiative pour une méthode publique. Elle repose sur une analyse du Système Entreprise et de sa logique interne. Les procédés qu’elle propose couvrent tous les aspects de l’entreprise, de l’éthique à l’infrastructure, de la connaissance à la logistique, en passant par les processus et l’organisation.
C’est une chose de disposer des méthodes pour chaque aspect de l’entreprise (les méthodes pour les stratèges, celles pour les organisateurs, celles pour les informaticiens ou les comptables, etc.) ; c’en est une autre de les articuler soigneusement afin d’obtenir une chaîne de transformation harmonieuse. Le souci originel de Praxeme est justement de répondre à ce besoin de coordonner des spécialités disparates, également légitimes et nécessaires, mais qui communiquent difficilement.

Ce besoin, le dirigeant d’entreprise ou d’administration le ressent en premier lieu, d’autant plus fortement que son organisation est confrontée au changement. Face à l’hétérogénéité des propositions, le décideur recherche un cadre général qui optimise l’investissement : s’il porte l’effort sur un point de la chaîne de transformation, s’il sacrifie aux sirènes du moment, il lui faut la garantie que cette action s’inscrive dans un plan plus vaste, déployé dans toutes les dimensions de l’entreprise. Il cherche également les moyens de stimuler l’innovation, non seulement en reprenant les recettes de ses concurrents ou en adoptant les dernières technologies, mais aussi en revisitant le métier, en se décentrant, en se réinventant. Or, la psychologie humaine, les forces de conservation, les jeux d’acteurs… tout conspire pour empêcher cette transformation.

Aussi est-il d’une absolue nécessité de disposer d’une méthode qui révèle les phénomènes à l’œuvre et qui offre les moyens concrets de les dépasser. Le premier apport de Praxeme consiste en la prise de conscience de la complexité et la reconnaissance des univers cognitifs qu’il faut relier et mettre à contribution. Éthique, terminologie, métrologie, modélisation, sociologie, architecture de systèmes sont quelques-unes des disciplines qui permettent d’approcher la réalité de l’entreprise. Elles produisent des représentations que la méthode aide à formaliser et à relier. Par exemple, la conception des processus s’inspire des exigences éthiques, c’est-à-dire des valeurs déclarées par l’entreprise. Ou encore, le système informatique découle des modèles métier, selon des règles de dérivation qui garantissent son alignement et son agilité.

Praxeme a été appliquée à des échelles variables et dans tous les secteurs d’activité. Les applications incluent la refonte des systèmes d’information, l’innovation dans les systèmes d’armement, la modélisation des systèmes de transport, l’évolution des pratiques, la convergence entre systèmes ou métiers d’une fédération d’entreprises, l’interopérabilité. L’administration française, pour mener ses grands programmes de modernisation de l’action publique, recommande l’usage de cette méthode.

Étant donnée son ambition, Praxeme est un chantier permanent. L’initiative se veut ouverte, au double sens où elle accueille les contributions et où elle met à disposition ses résultats, libres de droits. Une première version est disponible sous la forme de guides méthodologiques qui posent les fondements. La version 2 est en cours de rédaction et complète le corpus par des fiches de procédés destinées aux différents acteurs des transformations.

Le Praxeme Institute, association sans but lucratif et reconnue d’utilité publique, coordonne les travaux et veille au respect de l’esprit d’ouverture.
Pour plus d’information :

Dominique Vauquier

Aspects et vues

La Topologie du Système Entreprise, le cadre de référence proposé par Praxeme, identifie des aspects. Cette notion a souvent soulevé des questions ou a été confondue avec celle de vue. Le terme “vue” est le plus utilisé dans la littérature méthodologique des deux dernières décennies. Ce billet précise les deux notions et justifie le maintien du terme “aspect” aux fondements de la méthodologie d’entreprise.

Vue

Sources : « vue » et « point de vue » dans IEEE Std 1471-2000. Cigref et Club Urba.
Une vue suppose un acteur qui regarde. Elle donne accès à une partie de la réalité observée, à partir du point de vue de cet acteur. Elle exprime donc la subjectivité : la situation du sujet face au réel. Son avantage réside dans la communication puisque, justement, elle s’établit par rapport aux besoins et au langage d’un certain type d’acteur.

Niveau

La méthodologie, notamment avec Merise, a longtemps parlé en termes de niveaux d’abstraction ou niveaux de préoccupation. Ces niveaux étaient clairement distincts des vues, lesquelles étaient également définies, à la même époque et dans les mêmes méthodes. Alors, les niveaux étaient donnés comme plus fondamentaux, plus essentiels que les vues. Ces méthodes définissaient d’abord les niveaux comme exprimant la structuration interne du système. Les vues étaient ainsi définies secondairement dans leur rapport aux acteurs et pour des besoins de communication. Par exemple, Merise distinguait les « vues externes » du modèle de données : celui-ci donne la structure de données complète et normalisée, tandis que celles-là en présentent un extrait, éventuellement dénormalisé, pour un certain usage.
Le terme « niveau », néanmoins, était malheureux dans la mesure où il infère une certaine idée de hiérarchie donc de valeur.

Aspect

Il est évident, en tout cas, que nous avons besoin de deux notions. Quand nous regardons un cube, par exemple, nous n’en voyons jamais toutes les faces. Nous pouvons nous en former plusieurs représentations, en prendre plusieurs vues et il nous faudra tourner autour de l’objet pour en percevoir toutes les faces.
Quand nous cherchons à nous représenter complètement le cube et à articuler les vues, il est bon de savoir que cet objet possède six faces, même si cette idée ne nous est pas donnée par l’expérience mais par l’entendement. La géométrie vient avant le dessin.
Le cadre de référence au fondement de Praxeme vise l’organisation interne du Système Entreprise, indépendamment de qui l’observe. C’est un préalable pour maîtriser la masse des connaissances, des informations et des décisions qui portent sur cet objet complexe. Nous cherchons à en dégager la logique interne, en préalable à tout développement méthodologique et bien avant de traiter les questions impliquant les acteurs : responsabilité, organisation de la transformation, communication, etc. Ce faisant, Praxeme s’inscrit dans la filiation de Merise par opposition aux méthodes anglo-saxonnes qui, au fil des décennies, n’ont retenu que la notion de vue et se sont focalisées sur la communication au détriment de la logique interne du système.
Pour qualifier ces domaines structurant la réalité de l’entreprise, indépendamment de l’observateur, Praxeme a retenu le terme « aspect ».

Illustration de la différence entre aspect et vue

Cette distinction, essentielle pour la théorie de la connaissance, se révèle dans l’usage des deux termes et dans les qualificatifs qui les accompagnent. Nous l’illustrons, dans ce paragraphe, à propos de l’aspect intentionnel tel qu’il est défini dans la Topologie du Système Entreprise. Cet aspect, le premier dans l’ordre des déterminations, rassemble toutes les expressions de la volonté de l’entreprise : ses valeurs, ses objectifs, les exigences, les indicateurs (souvent intimement associés aux objectifs), son vocabulaire.
Praxeme n’impose pas de structuration de cet aspect. La méthode se contente de distinguer les types d’éléments d’intention, laissant la possibilité de structurer cet aspect comme on l’entend. Il y a donc une décision d’architecture à prendre aussi pour l’aspect intentionnel :

  • soit on le structure par les sources (les émetteurs ou les documents d’origine qui comportent souvent des éléments de plusieurs natures),
  • soit on opte pour un critère propre, avec une notion de domaine comme pour n’importe quel autre aspect.

Ainsi, l’aspect intentionnel possède sa propre structure et obéit à ses propres lois qui ne reflètent pas nécessairement les usages. Dès lors, il devient intéressant de définir des vues qui faciliteront la communication avec des acteurs de profils précis, par exemple :

  • une vue éthique, centrée sur les valeurs de l’entreprise et comportant également leurs impacts sur les autres aspects du Système Entreprise ;
  • une vue métrologique, composée des indicateurs, de leurs liens avec les objectifs de transformation et, aussi, de leur projection vers les concepts métier, les activités ou tout autre type d’élément dans les autres aspects ;
  • une vue terminologique, exprimée par le thesaurus de l’entreprise et montrant, outre les termes, les liens de traçabilité qui les relient à d’autres éléments.

Ces sous-produits que sont les vues répondent à des besoins de communication et de manipulation ; elles sont donc associées à des utilisations. La méthode doit satisfaire ces besoins sans altérer la logique de structuration interne du Système Entreprise. C’est ce qu’elle obtient en distinguant les deux notions d’aspect et de vue.

Continue reading

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.

Formaliser la connaissance

En réponse à la demande d’un client, Dominique VAUQUIER tire au clair les différents moyens d’exprimer la connaissance. C’est l’occasion pour formuler des réflexions qui traînaient au sein du Praxeme Institute, surtout depuis les ateliers des professeurs Loïc DEPECKER sur la terminologie et Christophe ROCHE sur les ontologies.

L’article repose sur l’idée que les techniques à notre disposition pour exprimer les connaissances s’échelonnent selon le niveau de formalisation. Plus l’effort consenti est important, plus grandes sont les possibilités d’automatisation.

En pratique, les entreprises que le sujet préoccupe pourront arrêter une démarche progressive, mettant à profit différentes techniques : le classement de documents à l’aide de taxinomies, l’élaboration de la terminologie d’entreprise, le développement d”ontologies, la modélisation – particulièrement la modélisation sémantique.

Télécharger l’article