Cette discussion sur les domaines m'évoque la notion de recueil des besoins.
Dans les deux cas, j'ai l'impression qu'on essaie de réifier ce qui est au
départ une série d'actes, de réflexions et de conversations, dans un document.
Dans de nombreuses entreprises, mais surtout les grandes qui ont beaucoup
d'argent à dépenser en "études" (alors qu'elles feraient mieux de le dépenser en
self-help) on a cristallisé ces activités : conception, expérimentation,
recherche, dans les documents qui résultent de ces activités. Cette transition
est sensible si l'on fait attention à la substantivation des mots; si typique
dans l'usage du mot "design" (comme dans : "faire un design", "puis implémenter
ce design", ces deux étapes traduisent à la fois une représentation figée et une
stance de pouvoir concepteur vs programmeur).

Je pense que cela a été fait de manière à pouvoir définir un processus dans
lequel des documents sont placés en entrée de phases et des documents sortent
des phases vers d'autres phases. Cette description mécanique, empruntée aux
fluides ou encore à l'électronique et à l'informatique elle mêmes (input /
output) est très pratique d'un point de vue bureaucratique (qui est responsable
de quoi à quel moment ?) mais aussi une grande source d'illusions. Une de ces
illusions pour moi est la notion de "domaine" qui se tiendrait quelque part,
objective, distante à la fois des utilisateurs (qui s'ignorent eux même dans
leur activité et ont besoin d'un maïeuticien "moderne" : l'assistant MOA) et des
développeurs (qui ignorent tout du "domaine" métier puisqu'ils sont imprégnés du
"domaine" technique, comme j'ignorerais tout des échecs parce que je pratique le
piano).

Evidemment ce "domaine" n'existe pas. Je ne peux pas dire d'un consultant A
qu'il a "identifié le domaine" alors que B ne l'a pas trouvé. L'idée qu'un
groupe humain puisse produire à propos de lui-même et de ses activités un
discours objectif, scientifiquement observable, n'existe plus que dans les
comités de pilotage des grands projets informatique, et peut être dans les
bistrots, tard le soir. Cette idée a été abandonnée par la philosophie et la
sociologie il y a plus de 100 ans. On peut évidemment dire que la philosophie et
la sociologie ont échoué là ou la grande banque ou le cabinet de conseil en
urbanisation réussissent tous les jours, mais ce serait un peu facétieux. Ce
n'est pas parce que je gagne ma vie à tenter de simplifier les problèmes de mes
clients que je peux prétendre décrire quoi que ce soit d'objectif.

Justement, le "domaine" est pour moi un simple concept opératoire, une
représentation qui sert à résumer l'ensemble des propositions effectuées par un
consultant à propos d'une création subjective qu'il fait à partir de dialogue,
d'observation, de réflexion technique etc.. Autrement dit, le "domaine" c'est ce
que je dis à propos de ce j'ai observé. C'est une représentation. C'est aussi un
ensemble de décisions (de périmètre, de limitations, d'interprétation...). Le
fait que j'emploie des mots sur lesquels les autres s'accordent ne rend pas
cette desription plus "fidèle" à une réalité qui se tiendrait là.

A partir de là, la question n'est plus "quel est, objectivement, le domaine du
problème de l'utilisateur ?" mais plus directement : "quelles représentations
me sont le plus utiles à construire le logiciel qui conviendrait à l'utilisateur
?"

La suppression de cette notion de domaine "en soi" au profit de concepts
opératoires utilisables dans un contexte bien précis de création de logiciel
amène à mon avis plusieurs conséquences importantes :

- le "domaine" se tient entièrement dans ses représentations (et pas ailleurs)
et alors se pose la question de savoir quelle représentation est la plus utile
dans le contexte de la création d'un logiciel, et en quoi tient cette utilité.
Pour moi, l'utilité qu'on tire en général des représentations présentes dans un
logiciel, c'est de pouvoir faire évoluer ce logiciel. Par conséquent plus les
représentations sont proches de la "machine" qui a pour nom programme, plus il
sera facile de les changer pour que cette machine fasse quelque chose de
différent. A l'extrême, la manière la plus simple de changer un programme, c'est
de remplacer une valeur binaire par une autre (ce que firent les premiers
informaticiens sur les premiers ordinateurs avant de créer les premiers éditeurs
hexadécimaux puis les "assembleurs"), mais cette valeur binaire n'est que
lointainement associée aux représentations élaborées avec l'utilisateur. Pour
prendre un exemple intermédiaire , si mes discussions avec l'utilisateur me
conduisent à un programme dont le but serait de calculer la TVA au taux normal
sur des montants, la représention x = y * (1+z) ; en langage C est une
représentation efficace pour l'implémentation du programme. Mais en même temps
les représentations pour la "machine" doivent conserver une relation plus
étroite si possible avec les termes issus des discussions avec l'utilisateur,
pour le cas où de nouvelles discussions avec cet utilisateur (ou son successeur)
en vue de modifier le programme seraient à prévoir. Dans mon exemple, il serait
préférable -- plus maintenable -- d'écrire montantTTC = montantHT * (1+tauxTVA).

- les langages informatiques modernes sont aptes à véhiculer raisonnablement
correctement les représentations utiles aux logiciels recherchés dans une grande
majorité de cas. Il n'est pas exclu que des programmes répondant à des buts
nouveaux exigent un jour d'autres langages encore plus modernes. (Quels seront
les langages de l'informatique quantique, par exemple ?) En revanche ce que nous
constatons dans la grande majorité des cas, c'est que cette aptitude /n'est pas/
utilisée. Par exemple, en C++, lorsque j'écris tot2 = tot1 * (1+zozo) au lieu de
montantTTC = montantHT * (1+tauxTVA) ou lorsque je duplique du code, ou encore
lorsque je me refuse à utiliser l'héritage ou que j'écris mes propres
"conteneurs", je sous-utilise clairement la capacité de représentation du
langage qui m'est donnée, ce qui induit des représentations intermédiaires, des
"traductions", représentations que nous croyons devoir systématiser sous forme
de document autonomes appelés à tort "modèles" (car ce sont des schémas, et non
des modèles). Cette sous utilisation n'est pas simplement fortuite ou
accidentelle, comme dans le cas du développeur inconscient qui nomme une
variable "zozo", elle est également organisée par l'industrie.

L'histoire des langages informatiques peut être entièrement articulée autour de
cette progression de la capacité de représentation : identifiants, puis types,
puis héritage, puis types paramétrés, et enfin fermetures lexicales. Cette
progression montre l'effort fantastique des concepteurs logiciels à améliorer la
notion de "représentations exécutables" qui est unique à l'informatique, et la
futilité des efforts inverses de multiplication des re-présentations/traductions
(le plus bel exemple en est MERISE qui a posé deux axes : 1) conceptuel ->
organisationnel -> logique -> physique 2) traitement - données - flux, a fait un
produit cartésien des valeurs sur ces axes et en a absurdement dérivé une
matrice de modèles, MCT, MOT, MCD, MPD etc., ainsi qu'un processus complet de
remplissage pour cette grille. Méthode commandée par la bureaucratie, et que
seule une bureaucratie pouvait désirer, dans son fantasme de ranger chaque
responsabilité pour chaque étape. Il va de soi que MERISE est sous-exploitée
partout où on l'utilise, ce qui est plutôt rassurant).

La "traduction" est un vieux remède aux anciennes limitations des anciens
langages (longueur maxi des identifiants, rareté de la mémoire, temps
d'exécution ralenti des programmes "structurés" etc, et aujourd'hui encore les
"temps de réponses catastrophiques" sont souvent invoqués dans les objections
chargées de retarder l'avènement des langages fonctionnels purs). Mais la
"traduction" est devenue "tradition". C'est cette tradition qui fonde les usines
à modèles comme UML aujourd'hui. Il est remarquable qu'une entreprise comme
Rational gagne de l'argent à poursuive un but aussi contradictoire que celui qui
consiste d'une part à éloigner la représentation le plus possible de la
"machine" (l'abstraction qui exécute le programme) déployant un festival de
représentations graphiques en deux dimensions (alors que la machine utilise une
représentation linéaire, narrative, au mieux algébrique) d'autre part à tenter
de produire automatiquement le code opérationnel "correspondant" à ces
représentations graphiques, via génération automatique vers un langage cible,
c'est à dire à *rapprocher à nouveau* ces représentations de celles propres à la
"machine" pour tenter l'implémentation automatique des programmes "schématisés"
par l'utilisateur. A mon sens cette double manoeuvre divergente ne perdure
économiquement malgré la contradiction que parce que les clients de cette
entreprise sont aveuglés par une idéologie dans laqu'elle il n'est pas exlu de
pouvoir un jour supprimer le "développeur" (le technicien, le geek, le "nerd",
l'inadapté) du modèle social. Cette contradiction est même entretenue par le
choix du langage chargé d'implémenter automatiquement les "modèles". Si l'outil
rational génére du C++ (et non du Eiffel, du Smalltalk, ou du Haskell) cela
tient justement au fait que la distance doit être artificiellement maintenue
entre un graphisme enrichi en modes de représentation et un langage relativement
frustre, obscur et compliqué comme C++. Etant donnée la difficulté qu'il y a à
produire des applications complexes à partir de code autogénéré depuis des
représentations graphiques (tabulaires ou arborescentes, en fait) il ne serait
pas judicieux de produire un code généré dans représentations plus simples et
plus expressives telles qu'on en rencontre maintenant dans des langages plus
évolués, de peur que l'utilisateur en revienne à taper du code au lieu de tracer
des schémas.

- la capacité grandissante de représentation que possèdent les langages de
programmation modernes, associée aux outils efficace pour tester la non
régression, ainsi qu'à la création d'un langage formel de "gestes" de design
appelés "refactoring", permettent de transposer une grande partie du processus
de conception (c'est à dire le triage, le classement, la projection, ainsi que
tout le travail de (micro-)décisions effectué par l'équipe à partir des
discussions avec l'utilisateur) vers le langage de programmation lui-même au
lieu de la planche à dessin ou du traitement de texte. C'est le sens d'une
phrase comme "The code is the design". Le succès de l'approche TDD pour le
design d'applications montre que la multiplication de "niveaux" de
représentations n'est pas strictement nécessaire à la pertinence d'une solution.
On peut bien sûr gagner de la précision et de la pertinence à représenter sous
différentes formes une même conception, mais cela coûte en général beaucoup plus
cher, d'autant que les multiples représentations sont rarement examinées en
détail ni invalidées, et que lorsque l'implémentation vient à contredire les
documents et les schémas, ces dernier sont très rarement mis à jour.

En résumé, à mon sens, l'activité de modélisation chère au bureaucrates et leurs
fournisseurs d'AGL et de consultants, est une vieille pratique issue des
problèmes initialement rencontrés pour concevoir facilement des logiciels à
l'aide de langages informatiques trop rudimentaires. A ce titre, le foisonnement
des "notations" graphiques dans les années 80 traduit typiquement une inquiétude
face à la jeunesse, au manque d'empreinte "mainstream" des langages à objets qui
émergeaient alors (parfois après deux décennies de gestation "académique").
Maintenant la notation est "unifiée" et le processus "rationnel". Ce processus a
créé une idéologie du modèle. Dans cette idéologie, le schéma, le diagramme, le
graphisme, outils de contrôle, (initialement outils du cadre de l'industrie
avant d'être un outil d'informaticiens) possèdent la valeur. A l'opposé, le
code, matériau technique, est de faible valeur (comparez le salaire d'un
analyste avec celui d'un développeur), il est même dégradant (comme dans "il est
analyste métier mais il met de temps en temps les mains dans le /cambouis/").
Il n'y a pas un schéma de processus méthodologique dans lequel vous trouverez
l'activité de modélisation en bas et le code produit en haut. Ce n'est pas une
question de gravité, mais d'echelle sociale. Cette idéologie vise à supprimer le
rôle du développeur comme "créateur", "visionnaire", "artiste" (et même
"artisan"), "asocial" et vaguement incongru dans la représentation sociale de
l'entreprise, et tel qu'il est revendiqué en retour avec force par des
"représentants" de la communauté geek comme Raymond voire à l'extrême, Stallman.
La logique de cette "élimination" symbolique peut se deviner facilement : le
développeur, individu cultivé, cadre, vit dans la créativité, le projet, le
changement (par exemple il est inconcevable pour un développeur ambitieux de
rester sur la même technologie durant dix ans), ce qui fait de lui un
incontrôlable. (La raison de vivre des SSII, c'est de fournir depuis 20 ans la
main d'oeuvre intérimaire en missions longue (5 ans et plus) que les entreprises
clientes, bien qu'elles investissent à long terme dans leur informatique, se
refuse à embaucher "en fixe"). Une autre raison "d'éliminer" le développeur
tient au fait qu'idéologiquement l'entreprise ne peut le cantonner à un rôle de
technicien, subordonné, non cadre (cette "stratégie" a été commencée en France,
où l'on a d'abord formé des informaticiens en IUT ou BTS avant d'en venir au
temps ou les clients ne recrutent plus que des "bacs + 5"). En effet,
l'entreprise ne peut pas prendre le risque de voir se former un corps
d'informaticiens subordonnés avec une forte solidarité et un faible salaire
étant donné la valeur qu'elle retire de son système informatique et le coût que
provoquerait une résistance de ce corps (savez vous ce que perdrait une banque
en trois jours d'arrêt de son SI ?).

Comme elle ne peut pas le "contenir" dans un statut privilégié de créateur
individuel, ni le contraindre à un statut moins privilégié par peur d'un
soulèvement, l'entreprise, depuis le début de son informatisation en masse tente
d'"éliminer" le développeur. La première tentative est la modélisation à
outrance, à laquelle les méthodes agiles ont fait une réponse à la fois
"pragmatique" et sociale (Beck dans XPe1 : "XP place le développeur au coeur du
processus de création de logiciel" cit. approx.) la seconde est l'offshore,
stratégie de faire-faire visant autant à réduire les coûts que les risques de
"coups", tentative à laquelle rien ne fait réponse pour l'instant.


Note to Manu : Ai-je suffisamment déconstruit la notion de modélisation ?

--ct
----- Original Message -----
From: bernard_notarianni
To: xp-france@...
Sent: Friday, January 20, 2006 7:34 AM
Subject: [xp-france] Re : Re : Re : La cascade avait raison...?


--- Dans xp-france@..., Herve AGNOUX <herve.agnoux@d...> a
écrit
>
> Le Mercredi 18 Janvier 2006 18:50, bernard_notarianni a écrit :
> >
> > L'important est que le modèle mental des développeurs correspondent à
> > quelque chose en rapport avec le modèle mental de l'utilisateur. C'est
> > le point crucial du projet informatique.
> >
>
> Il faut surtout qu'il corresponde au domaine à informatiser ! Le
modèle des
> développeurs et de l'utilisateur peuvent correspondre, s'il ne
correspond pas
> au domaine, ils n'arriveront à rien.
>

Hervé, qu'appelle tu un "domaine"? J'ai l'impression à te lire que tu
raisonne en pensant qu'il existerait quelque part une chose appellée
"domaine" indépendante des hommes qui en ont besoin et des hommes qui
vont l'implementer. Cette chose peut etre "bonne" selon un certains
nombre de critère.

Ai-je bien compris ta vision?
Si oui, quels seraient les critères qui te permettent de dire "ce
domaine est bon"?


[...]

> Les échanges utilisateurs / développeurs ont leur importance. Mais,
là encore,
> tu inverses, si je puis me permettre. En milieu complexe, la
justesse du
> modèle facilitera la communication, et non pas la communication
favorisera la
> justesse du modèle.


cf question ci dessus.

>
>
> >
> > PS: je parle ici d'applications de gestion, et non pas d'applications
> > scientifiques ou industrielles.
> >
>
> De toutes façons c'est le même topo quelque soit le domaine.
>

Je commence à mieux comprendre pourquoi nous avons du mal à nous
comprendre :-)

Je travaille exclusivement sur des applications de gestion, dont le
but est d'automatiser des processes humains. Le domaine que
j'implémente est un processus humain. Or comme tu le sais, le humains
sont très difficilement, modélisable et en plus, leur modèle change en
permanence. C'est pour ca qu'une application de gestion en apparence
simple (genre une compta) peux s'avérer très complexe à mettre en
oeuvre. On pourrai etre tenter de dire que "c'est parce les specs
changent tout le temps", ce qui est vrai mais cela fait partie
intraséque du domaine.

Il existe d'autre domaine, scientifique et industriel, qui visent à
implémenter des "modèles mathematiques et physiques" connus et
démontrable. Par exemple, le système de pilotage d'un airbus
implémente des règles de gestion connues, qui ne sont autre que les
equations correspondant aux lois physiques qui maintienne l'avion en
vol. Dans ce cas, je suis d'accord avec toi, soit le logiciel
implémente bien ces lois, et elles ont interet à etre juste, soit le
logiciel est bon à mettre à la poubelle.

Donc, je ne crois vraiment pas que ce soit le meme topo quel que soit
le domaine.








------------------------------------------------------------------------------
Liens Yahoo! Groupes

a.. Pour consulter votre groupe en ligne, accédez à :
http://fr.groups.yahoo.com/group/xp-france/

b.. Pour vous désincrire de ce groupe, envoyez un mail à :
xp-france-desabonnement@...

c.. L'utilisation de Yahoo! Groupes est soumise à l'acceptation des
conditions d'utilisation.



[Les parties de ce message comportant autre chose que du texte seul on été
supprimées]