Un logiciel vaut le coût que l’on est prêt à y mettre. Et en décortiquant l’ensemble des coûts et temps passés, il n’est pas anormal d’avoir seulement la moitié du temps qui est de l’ingénierie logicielle et des tâches techniques. Rien de plus logique, d’autant plus que le développement n’est pas un résultat mais une activité. Ce qui signifie que tous les produits livrés ne se ressemblent pas et que le contexte, la complexité, les interlocuteurs et les compétences font varier grandement les coûts.
Typiquement un projet logiciel se rapproche de la construction d’une maison. Suivant l’architecte, les plans et les demandes des utilisateurs, le résultat peut être très différent. Cette approche qui tente de mimer les projets du monde « réel » tend à être dépassé aujourd’hui au profit des approches dites « agiles » dans lesquels le projet évolue durant sa construction. Néanmoins, les fondamentaux restent en majorité les mêmes.
Ce qui coûte vraiment dans un projet informatique, c’est :
- Le temps passé à réaliser concrètement le logiciel (le code, la base de données…) : tout le monde pense à ce poste de dépense.
- Le temps passé à border le projet : quelles vont être les grandes fonctionnalités ? Comment doivent-elles s’agencer les unes avec les autres ? Qui dirige le projet ? Dans quel ordre les fonctionnalités doivent-elles être développées ?
- Le temps passé en échange, analyse, compréhension du besoin avec le client et les utilisateurs finaux. À noter que si cette étape est négligée, il y a de fortes chances que le projet déborde complètement. Une bonne préparation est indispensable.
- Le temps passé à mettre de l’huile dans les rouages, à mettre les différents intervenants au même niveau d’information et à gérer au fil du temps le projet. C’est une vraie tâche de gestion de projet qui prend toujours plus de temps que prévu.
- Le temps passé à tester. Cela est prévu côté SSII (tests unitaires, tests d’intégration) mais souvent délaissé et considéré comme une tâche subalterne côté client (tests fonctionnels et recette). Pourtant cette étape est indispensable et permet de lever les bugs les plus courants. Pour que les tests soient vraiment efficace, il faut les faire avec application en utilisant de vraies données côté client.
- Le temps passé à corriger. Même le meilleur développeur fait des erreurs. Seuls ceux qui n’ont jamais travaillé dans un environnement pro n’affectent pas de temps au débuggage. Ce temps peut dépasser 40% du temps du projet. Ce n’est pas parce que les informaticiens sont mauvais, c’est parce que la complexité est importante et que le cerveau à toujours tendance à tout simplifier à outrance.
- Le temps passé à rédiger la documentation. Indispensable à la fois chez le client pour pouvoir facilement utiliser l’outil même si les personnes à l’origine du projet ne sont plus là et chez le prestataire pour soulager le support à moyen terme.
- Le temps passé à former les utilisateurs.