e lisais récemment sur un newsgroup de développement, que le plaisir dans la programmation venait de s'arracher les cheveux pendant des heures sur des problèmes, plutôt que d'utiliser des ateliers de développement.

Moi, c'est de lire cela qui me fait m'arracher les cheveux.

Les arguments avancés par certains est que l'on ne voit pas le code qui est écrit, il y en a trop, l'outil ne répond pas à tous les cas de figure.

Je vais poursuivre le débat en étudiant d'une part la vivacité réelle des ateliers de génie logiciel (AGL) et leurs atouts, et en analysant d'autre
part leurs contraintes inhérentes, qu'il vaut mieux maîtriser que contourner.

Les AGL et leurs atouts

Si la programmation est une source de plaisir, (et je suis de ceux qui apprécient de concevoir et développer des applications) il ne faut pas oublier que l'objectif premier et ultime des informaticiens et de rendre un service à un utilisateur.

Le temps des budgets informatiques incontrôlables est fini. Nous devons rendre ce service à moindre coût, dans des délais courts, avec un degré de qualité et de fiabilité accrue. Et seuls des outils permettent ce qu'il faut bien appeler des gains de productivité.

Il est évident que dans le monde de l'informatique, les ateliers de génie logiciel ont fait leur preuve. Je ne connais pas l'informatique industrielle, mais dans les traitements de gestion, c'est le cas. Ce n'est pas la panacée, mais il ne faut pas perdre de vue la règle des 80-20, à savoir dès qu'un automate rempli 80% de la mission qui lui était confiée, il faut s'en contenter. Car vouloir atteindre 90% ou plus de façon automatique va coûter aussi cher que la réalisation des 80 premiers pour cent ! Le HTML n'est pas de la programmation, mais la mise en place d'un site internet relève de la même logique.

Un outil de production automatique évite un grand nombre d'erreurs syntaxiques, parfois très coûteuses en temps de debuggage. Et quand on programme pour une entreprise, on n'a pas le droit de se mettre en situation de devoir résoudre des anomalies dues à ce type de fautes.

Il y a d'autres aspects intéressants : un véritable AGL doit pouvoir gérer un dictionnaire d'informations réutilisables. Et les analyse qualité sur la programmation (respect des normes etc..) sont plus faciles à réaliser sur un code produit par un automate que celui produit par un humain. La gestion des relations entre composants, n'est pas une mince affaire non plus, avoir des include c'est bien mais si ne sait pas qui utilise qui, on est mal lors de la maintenance de la brique élémentaire ! Cette gestion de configuration prendra de plus en plus de place sur le web, cela permettra par exemple de migrer rapidement un site vers un autre hébergeur ou une autre technologie.

Les outils et leurs contraintes

Un des plus gros reproches que l'on peut à ces outils d'écriture automatique est leur verbiage. C'est normal, ce ne sont pas des experts, ils doivent gérer le général. Quand ce verbiage disparaît lors d'étape de livraison, ce n'est pas trop important, mais quand cela fait des Ko en plus/trop dans une page HTML, cela peut devenir insupportable. C'est un des critères de comparaison des éditeurs HTML wysisyg.

On n'a pas accès au code produit, c'est parfois le cas. Mais si le programme ou la partie de programme doit être retouchée après l'outil, il vaut mieux dans ce cas précis l'écrire complètement à la main.

Si l'on a l'impression que l'on doit manipuler le code après l'outil pour des cas de programmation courants (les cas très tordus sont rares), c'est sans doute que l'algorithme sous-jacent a été mal conçu. Pour pratiquer des AGL depuis plusieurs années, quasiment toutes les situations standards sont bien gérées par ces outils. Il faut parfois se poser la question dégrader l'algortihme ou écrire à la main, le choix est toujours financier en tenant compte du coût de l'écriture et du coût de la maintenance.

Conclusion

Les AGL et outils de production de code pour le web n'ont sûrement pas atteint leur maturité, cela va aller plus vite que pour leurs aînés, mais si leur ratio de productivité n'était pas important, les gros fabricants de code ne se tourneraient pas vers ce type d'atelier intégré. De plus ils vont coûter chers et ne seront pas accessibles à tous les budgets, on trouvera entre eux les mêmes différences qu'entre les éditeurs HTML actuellement.

Mais les économies réalisées par l'acquisition d'outils de développement intégré couvrent largement les surcoûts marginaux de développements spécifiques.

Nb : l'absence d'exemple et de nom est volontaire. J'attends vos réactions sur le forum SAM pour poursuivre le débat.

Daniel Lucazeau
Ajornet.com
Chef de projet Internet
Développeur informatique

Tous droits réservés - Reproduction même partielle interdite sans autorisation préalable