1.2 … et malheurs
19
© Dunod – La photocopie non autorisée est un délit.
Les professionnels du développement informatique sont confortablement outillés
pour répondre à ces exigences. Ils ont reçu un enseignement technique et théorique
solide, le plus souvent accompagné d’une expérience pratique de départ, expérience
qu’ils enrichissent rapidement sur le terrain. Ils disposent de méthodes de modélisation et de construction d’applications qui les guident dans leurs activités de production. Ils utilisent des environnements de développement puissants, tels les
dictionnaires de données, les générateurs d’application, les environnements de développement rapide (RAD), les librairies de composants ou les ateliers de génie logiciel.
Si l’état de l’art en matière d’outils de développement pour l’utilisateur, en
l’occurrence les tableurs et les systèmes de bases de données, évolue très rapidement, on ne peut en dire autant des aspects méthodologiques. L’utilisateur-développeur, qui n’est pas un professionnel de l’informatique, et qui le plus souvent ne
peut justifier d’une formation préalable solide, est confronté à des logiciels de plus
en plus puissants, de plus en plus difficiles à maîtriser, et surtout aborde des
problèmes de plus en plus complexes. Au contraire du développeur professionnel, il
ne dispose ni de modèles, ni de méthodes, ni a fortiori d’outils d’aide au développement. La situation est donc proche de celle du programmeur du début des années 60,
peu à peu conscient que la maîtrise de FORTRAN ou de COBOL ne suffit plus à la
construction systématique de programmes fiables et maintenables.
Les ouvrages largement disponibles chez les libraires, voire dans les grandes
surfaces, contribuent à masquer le problème. Destinés à l’utilisateur, ils présentent
une vision idéalisée du développement d’applications qui ne correspond pas à la
réalité. Combien de titres ne comportent-ils pas les mots simple, facile, pour les nuls
ou en un week-end? Non, Excel n’est ni simple ni facile dès qu’on attaque des
problèmes complexes. Comment pourrait-il en être autrement d’un logiciel dont la
documentation de base, notoirement insuffisante 1 , occupe plus de 1 800 pages?
Non, SQL n’est plus un langage naturel et sûr, dès qu’on s’éloigne des requêtes
élémentaires. Il ne l’est pas plus que la logique mathématique, dont il n’est qu’une
expression lisible certes, mais maladroite, incomplète, irrégulière voire contradictoire (voir la section 6.10 par exemple).
Il existe peu de résultats publiés concernant la qualité des applications réalisées
par des utilisateurs, tant en bases de données que sur tableurs. Nous citerons deux
références qui abordent le problème. [Ronen, 1989] attire l’attention sur le problème
de la qualité des modèles de calcul, propose une classification des erreurs et suggère
une démarche de construction systématique et raisonnée. [Brown, 1987] va plus loin
et fait état d’une analyse quantitative des types d’erreurs. Les résultats sont rien
moins qu’inquiétants. Nous les résumons 2 .
Neuf utilisateurs de tableurs chevronnés (1 à 5 années d’utilisation, 2,7 en
moyenne) ont été soumis à des tests consistant à réaliser trois modèles simples en
1. D’où la prolifération d’ouvrages de complément, souvent indispensables, tels que [Kyd, 1992]
ou [Blattner, 1999].
2. Voir aussi [Teo, 1999].
19
© Dunod – La photocopie non autorisée est un délit.
Les professionnels du développement informatique sont confortablement outillés
pour répondre à ces exigences. Ils ont reçu un enseignement technique et théorique
solide, le plus souvent accompagné d’une expérience pratique de départ, expérience
qu’ils enrichissent rapidement sur le terrain. Ils disposent de méthodes de modélisation et de construction d’applications qui les guident dans leurs activités de production. Ils utilisent des environnements de développement puissants, tels les
dictionnaires de données, les générateurs d’application, les environnements de développement rapide (RAD), les librairies de composants ou les ateliers de génie logiciel.
Si l’état de l’art en matière d’outils de développement pour l’utilisateur, en
l’occurrence les tableurs et les systèmes de bases de données, évolue très rapidement, on ne peut en dire autant des aspects méthodologiques. L’utilisateur-développeur, qui n’est pas un professionnel de l’informatique, et qui le plus souvent ne
peut justifier d’une formation préalable solide, est confronté à des logiciels de plus
en plus puissants, de plus en plus difficiles à maîtriser, et surtout aborde des
problèmes de plus en plus complexes. Au contraire du développeur professionnel, il
ne dispose ni de modèles, ni de méthodes, ni a fortiori d’outils d’aide au développement. La situation est donc proche de celle du programmeur du début des années 60,
peu à peu conscient que la maîtrise de FORTRAN ou de COBOL ne suffit plus à la
construction systématique de programmes fiables et maintenables.
Les ouvrages largement disponibles chez les libraires, voire dans les grandes
surfaces, contribuent à masquer le problème. Destinés à l’utilisateur, ils présentent
une vision idéalisée du développement d’applications qui ne correspond pas à la
réalité. Combien de titres ne comportent-ils pas les mots simple, facile, pour les nuls
ou en un week-end? Non, Excel n’est ni simple ni facile dès qu’on attaque des
problèmes complexes. Comment pourrait-il en être autrement d’un logiciel dont la
documentation de base, notoirement insuffisante 1 , occupe plus de 1 800 pages?
Non, SQL n’est plus un langage naturel et sûr, dès qu’on s’éloigne des requêtes
élémentaires. Il ne l’est pas plus que la logique mathématique, dont il n’est qu’une
expression lisible certes, mais maladroite, incomplète, irrégulière voire contradictoire (voir la section 6.10 par exemple).
Il existe peu de résultats publiés concernant la qualité des applications réalisées
par des utilisateurs, tant en bases de données que sur tableurs. Nous citerons deux
références qui abordent le problème. [Ronen, 1989] attire l’attention sur le problème
de la qualité des modèles de calcul, propose une classification des erreurs et suggère
une démarche de construction systématique et raisonnée. [Brown, 1987] va plus loin
et fait état d’une analyse quantitative des types d’erreurs. Les résultats sont rien
moins qu’inquiétants. Nous les résumons 2 .
Neuf utilisateurs de tableurs chevronnés (1 à 5 années d’utilisation, 2,7 en
moyenne) ont été soumis à des tests consistant à réaliser trois modèles simples en
1. D’où la prolifération d’ouvrages de complément, souvent indispensables, tels que [Kyd, 1992]
ou [Blattner, 1999].
2. Voir aussi [Teo, 1999].