En conclusion

l’utilisation d’un AGL en négligeant cet impact risque fort d’aller “ dans le mur ”. Les programmeurs trouveront toutes les raisons possibles et imaginables pour faire échouer le projet (trop de bugs, inadéquation de l’AGL aux besoins, etc…). Chez mon premier employeur, le choix de l’outil AGL utilisé n’était pas celui de la Direction, mais celui des équipes de développement, qui souhaitaient disposer d’un outil de développement performant, compte tenu des délais souvent très serrés que leur imposaient les utilisateurs. Certains des analystes programmeurs et chefs de projet en place avaient une forte culture RPG, mais n’ont eu aucun mal à  utiliser l’outil. Une deuxième cause d’échec peut aussi provenir de décideurs qui penseraient à  tort pouvoir faire des économies sur la formation. Le risque est grand dans ce cas, de voir les programmeurs écrire leurs programmes L4G comme ils écrivaient leur programmes RPG, sans utiliser toutes les ressources de l’outil, comme les macro-instructions, les règles de gestion, les fonctions, etc… Le retour sur investissement risque, dans ce cas, d’être long à  se manifester.