26 novembre 2006
La pensée aux prises avec l'informatique
"Systèmes d'information, obstacles & succès. La pensée aux prises avec l'informatique."
Laurent Bloch
* Contrairement aux mathématiques, l'informatique traite d'états.
"Le propos d'un programme informatique n'est pas de démontrer un théorème mais d'effectuer un traitement, [...] une action du processus consistant à consulter ou modifier l'état de la mémoire.
La mathématique ignore cette notion d'état, qui introduirait dans son univers d'abstraction un aspect physique totalement incongru.
Cest un peu comme si le papier sur lequel le mathématicien inscrit les signes du calcul avec un crayon acquérait un statut théorique."
(Il est intéressant de noter que les contraintes informatiques sont présentées comme issues de leur aspect "physique", alors que d'habitude la notion de virtualité ou d'immatérialité tend à isoler l'informatique comme un domaine flou, fantasmatique et autonome.)
* Il n'y a pas d'isomorphie entre un système d'information et le réel.
"Un SI n'est par nature qu'une représentation, une abstraction qui ne retient à propos de la réalité qu'elle représente que les informations qui importent à l'objectif poursuivi, exprimées avec la précision nécessaire, mais pas plus."
"Les données ne sont pas un élément tangible de la réalité, mais un artefact construit avec une intention déterminée, cette intention conditionne les interprétations qui pourront être faite de ces données" (Field theory of information).
Un système d'information ne traite que ce qui a été interprété comme donnée (une base comptable n'a pas besoin de faire interagir les descriptions techniques de ses items).
[Isabelle Boydens : Informatique, normes et temps.]
Ceci s'oppose à la métaphysique implicite des théoriciens des systèmes d'information ("Total data quality management"), qui prétendent circonscrire le réel comme un ensemble objectif de choses, propriétés, relations, dans des bases de données. De même pour les appellations "ontologies" ou "web sématique", qui sont une réduction de toute réflexion métaphysique et linguistique à de l'indexation automatique. "Le péché véniel d'enflure verbale finit par confiner à l'imposture intellectuelle, ce qui est plus gênant".
* L'informaticien doit concevoir la nature des données et de leurs changements d'état.
Chaque étape du travail de programmation peut amener à rédefinir quels traitements on demande au programme. C'est pourquoi la séparation entre conception et réalisaton (maître d'ouvrage/maître d'oeuvre) ne peut pas fonctionner. L'informaticien ne cherche pas des réponses, il cherche plutôt à chaque étape à sélectionner des questions qu'il va faire interagir entre elles.
D'où l'inadéquation de méthodes de management finalement issues d'autre domaines de travail (développement en V, Merise, SADT, méthode B, UML, représentation graphique, ISO9000).
[Frederick Brooks : The mythical man/month.]
[Alexandre Zinoviev : Les hauteurs béantes.]
* L'informaticien et son client doivent aborder problèmes et solutions de manière progressive.
Il faut définir de objectif généraux, pas de cahiers des charges rigide : il vaut mieux trouver d'abord des solutions imparfaites, mais efficientes, simples et modulables.(méthode dite "eXtreme Programming")
Itérations successives, on bâtit d'abord les étages avant les fondations, en plusieurs cycles : (prototype/suggestions/corrections). "Dès la fin de la première itération le système sera opérationnel, même s'il ne fait à peu près rien". D'où l'intérêt de pouvoir faire de multiples tests gratuitement, en récupérant du travail déjà fait (des modules open source).
Illustration avec l'histoire d'internet et les formats d'échanges qui l'ont emporté (les plus simples et souples, avec une couche réseau dite "non-fiable" car elle ne vérifie pas elle-même la bonne transmission des données mais laisse ce travail au récepteur), illustration avec le projet Socrate à la SNCF (mauvaise définition du besoin et des moyens).
Laurent Bloch invite donc à démythifier le travail de programmation, qui n'est ni travail mystérieux, ni pure tâche d'exécution : les clients doivent y participer, leur rôle est de définir à chaque étape leurs besoins et interprétations en terme de données et de traitements, tout en prenant connaissance des moyens et des contraintes spécifiques à l'automatisation de l'information.
Inscription à :
Publier les commentaires (Atom)
Aucun commentaire:
Enregistrer un commentaire