L’application, un concept brimant

… Qui a pourtant la vie très dure.

L’application est un regroupement de présupposés : on appelle ça couramment « les besoins utilisateurs » :

  • Soit on est un éditeur qui suppose a priori des besoins pour bâtir son business plan (quand il ne tente pas de les créer selon l’approche publicitaire classique) ;
  • Soit on est une DSI qui s’inquiète des besoins auprès de ses utilisateurs, en lui demandant de se prononcer sur la conception IT qui pourrait leur rendre des services.

Dans les deux cas, le résultat est un regroupement figé de solutions à des problèmes mal posés. Ce regroupement devient très vite un carcan. La question « qu’est-ce que vous voulez », ou pire la solution imposée sans même poser la question, conduit à figer dans le marbre les possibilités des utilisateurs. On est loin de la notion d’agilité que les concepts « ordinateur » et « programme informatique » véhiculent depuis des lustres.

Comment sortir de ce carcan ?

Un SI est un objet compliqué contraint de multiples façons, qui traite de nombreuses préoccupations, et qui est destiné à satisfaire une bonne quantité de personnes assumant une liste impressionnante de responsabilités. On ne peut l’envisager, le concevoir, le maintenir et le documenter d’une seule pièce. L’application est un découpage en éléments plus faciles à manipuler, aussi bien intellectuellement que pratiquement. Sortir du carcan de l’application impose donc de trouver un autre moyen de découper un grand sujet en une collection de sujets plus simples à apréhender.

Profitons-en pour ajouter un peu de sel à l’affaire : séparer un sujet d’intérêt en plusieurs parties est efficace uniquement si on n’oublie pas de les réunir ensuite. Dans le cas contraire, le résultat, certes apparemment simplifié, ne reflête plus la réalité et conduit immanquablement à des dysfonctionnements et à de misérables bricolages pour essayer de se rapprocher de la vraie vie. L’application assure bien un découpage, mais ne traite pas de la synthèse. D’où le classique et insurmontable chaos des flux applicatifs.

Donc, quel autre découpage ?

Tout le système est chargé de manipuler des objets métier, ceux qui ne sont qu’à peine suggérés par les fameuses « données » et, en revanche, scrupuleusement décrits et définis dans la modélisation sémantique. Ces objets ne sont pas indépendants, on note tout aussi scrupuleusement les liens indispensables (une ligne de commande n’existe que dans la cadre d’une commande) et d’autres plus lâches qui peuvent être temporairement oubliés (une ligne de commande porte une référence de stock mais peut exister sans). Et on se recule devant la collection d’objets : des galaxies apparaissent composées d’un ou deux objets centraux (commande) autour desquels gravitent des objets périphériques liés plus ou moins fortement (ligne de commande, produit, client, stock…). Ces galaxies sont les Domaines d’Objets. Elles servent de nouveau principe de découpage. A partir d’elles, on déduit les services métier, puis les services techniques nécessaires. De leurs comportements (les machines à états) on déduit les transformations qui ont du sens (autorisées). En regroupant les composants obtenus on crée les unités de déploiement. En utilisant les unités déployées on retrouve la synthése qui n’a jamais été perdue.

Et on atteint le mash up, l’agilité que l’approche service nous promet.

Publicités
Cet article, publié dans Méthode, Principes, Sémantique, est tagué , , . Ajoutez ce permalien à vos favoris.

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s