Leçons de niveau 15

Rôle de la communication dans le génie logiciel/Utilisateur et développeur

Une page de Wikiversité.
Sauter à la navigation Sauter à la recherche
Début de la boite de navigation du chapitre
Utilisateur et développeur
Icône de la faculté
Chapitre no 2
Leçon : Rôle de la communication dans le génie logiciel
Chap. préc. :Introduction
Chap. suiv. :Le rythme de la communication
fin de la boite de navigation du chapitre
Icon falscher Titel.svg
En raison de limitations techniques, la typographie souhaitable du titre, « Rôle de la communication dans le génie logiciel : Utilisateur et développeur
Rôle de la communication dans le génie logiciel/Utilisateur et développeur
 », n'a pu être restituée correctement ci-dessus.

Bien que la séparation entre l'utilisateur et le développeur de logiciel soit sujet à controverse, il est fréquent qu'une personne exprime un désir que l'autre réalise. Dans une optique industrielle on dit que le client fournit les spécifications du logiciel au développeur qui l'exécute. Dans une optique amicale on dit que mon pote a eu une super idée et que j’ai fait un logiciel qui l'implémente. Dans une optique autarcique on dit que j’ai fait un logiciel suite à une révélation pendant une nuit d'insomnie.

Dans ce dialogue, les tabous sont dominants. L'utilisateur considère que le développeur n'a pas à remettre en cause ses motivations ou la pertinence de son désir. Le développeur est admis à discuter des points techniques, par exemple si l'utilisateur demande un logiciel d'analyse de la pensée humaine. Par contre, s'il s'agit de réaliser le meilleur filtrage de l'internet au frontières d'un pays, un système de guidage de missile ou le meilleur moyen de contrôler les actes de l’utilisateur sans son consentement, la discussion devient impertinente. Les plus consciencieux objecteront et refuseront, mais ce cas extrême est en réalité très répandu sous des formes moins évidentes.

Par exemple, un utilisateur peut demander à un développeur de faire fonctionner une suite bureautique sur une toute petite machine. Le développeur s'exécute et produit des patchs qui viennent enrichir la suite bureautique. Tout le monde parait content. Mais en réalité l'utilisateur se sert d'une suite bureautique pour rédiger ses courriers électroniques et se satisferait parfaitement d'un éditeur de texte. Donc il n'a pas besoin de la suite bureautique. Donc le développement ne lui était pas nécessaire. Mais comme le développeur, en général, rechigne à s'intéresser au contexte dans lequel une demande lui est faite, il est fréquent que son travail soit en tout ou partie inutile.

Assez curieusement, il existe une abondante littérature sur les meilleures façon de formaliser les désirs techniques et pratiquement rien sur les méthodes permettant d'évaluer la pertinence d'un désir. Un bon avocat s'intéresse aux raisons pour lesquelles son client veut entamer une action en justice et soulignera volontiers l'incohérence ou la futilité de ses motifs. Le préliminaire à la réalisation d'un désir de logiciel devrait être, pareillement, de scruter attentivement les motifs et la pertinence du désir.