NoSoftwarePackage pour Not Only Progiciel (3/7) : le développement spécifique peut être efficace

Cet article fait partie de la suite d'article sur NoSoftwarePackage

Le contexte : 
Une question essentielle se pose lorsqu’un besoin informatique est identifié dans une entreprise. Doit-on construire la solution ou faut-il adopter une solution toute faite ? Dans la plupart des cas les entreprises orientent leur choix sur des solutions du marché, et les développements internes n’interviennent que si aucun logiciel n’existe ou seulement si aucun d’entre eux ne répond correctement au besoin.


Articles déjà publiés : 
Le développement est une solution trop risquée dans notre cas
Le développement n'est pas notre métier

Nous allons aujourd'hui essayer de répondre à une autre idée reçue sur...

Les développeurs ne sont pas efficaces

Un autre reproche fait au développement est que la mise en place d’une nouvelle application en interne prend beaucoup de temps et nécessite beaucoup d’effort. Une fonction métier qui peut être décrite en deux pages peut nécessiter des centaines de lignes de code, prenant des semaines à écrire et tester, et encore plus de temps pour être déployer sur les environnements de production. Par extrapolation un logiciel complexe prend des années à être construit. Comment améliorer le problème d’efficacité ? En augmentant le nombre de personnes ?

Le processus est t’il simplifié si l’on décide de mettre en place un logiciel ? On pourrait avoir un discours simpliste et  dire je lance un appel d’offre sur mon cahier des charges. Une fois que j’ai trouvé le logiciel qui répond le mieux à ce cahier des charges, j’achète la licence et je l’installe. Je pense qu’il serait intéressant de faire le tour des sociétés qui ont fait le choix de mettre en place des progiciels et de comparer leur budget initial, au budget réellement dépensé pour la mise en place, les coûts de licence, les coûts du changement, les coûts d’hébergement pour ceux qui préfère opter pour le cloud (c’est tellement mieux de confier ses données stratégiques à une grosse société qui aura ainsi tous les éléments en main pour faire monter les prix sans que vous ne puissiez rien dire). Et que dire si le périmètre fonctionnel évolue entre l’initialisation du projet et la mise en place de la solution.

Est ce que le développement présente autant de lacunes ? Bien sûr que non. Je ne dis pas qu’il n’existe pas de problème mais de nombreuses solutions sont intervenues ces vingt dernières années. Il faut que les responsables informatiques ouvrent les yeux et arrêtent de dénigrer ou de rabaisser les développeurs et observent les améliorations apportées par les nouveaux langages, les IDE (environnement de développement intégré), les méthodologies projets…

Les langages de programmation ont beaucoup évolué en devenant de plus en plus simple. Les développeurs n’ont plus besoin de gérer les mécanismes de libération de mémoire qui sont assurés directement par le système (garbage collector). La gestion des exceptions a totalement été revue permettant une gestion plus fine des erreurs d’une application. Les programmes ne sont plus dépendants d’une plateforme et peuvent être installés sur n’importe quel OS ou système d’exploitation. De nombreux frameworks ou librairies tierces sont à disposition pour encadrer les développements ou pour abstraire certaines fonctionnalités …. Par exemple si une application a besoin de fournir des exports aux formats Excel, Word, PDF ou autre, le développeur n’a pas besoin d’écrire le programme qui le fait et peut utiliser une librairie qui le fera pour lui.

Des systèmes de gestion des sources permettent le travail en commun et permettent de faciliter la gestion des versions des applications…

Les environnements de développements ont également complètement changé et permettent aujourd’hui de faire de la complétion, du refactoring, de générer du code, de déployer sur des environnements de tests, de lancer des tests, de packager…. Il existe de nombreux outils permettant de contrôler la qualité du code et de détecter certains bugs. Toutes ces fonctionnalités de plus en plus poussées sont possibles grâce à la rapidité des postes de développement.

Avec l’essor d’Internet, un développeur ne sera pas isolé et pourra trouver des solutions de déblocage sur les forums de discussion ou les sites de discussion. Les communautés derrière chaque technologie sont présentes en ligne ou physiquement dans toutes les grandes villes de France.

Au-delà des aspects techniques, les méthodes de gestion de projet ont aussi beaucoup changé avec l’avènement des méthodes agiles. Conscient des problèmes liés aux dérives des développements spécifiques, les acteurs du développement ont observé les solutions mises en pratique dans l’industrie pour rationaliser les chaines de production. Ces méthodes sont axées sur les individus et leurs interactions, et permettent de produire efficacement des logiciels de qualité. Ces méthodes reposent sur des cycles itératifs et incrémentaux qui permettent une amélioration continue de l’organisation et des processus.

Il n’est plus acceptable aujourd’hui d’entendre que les processus de livraison sont longs et complexes. De nombreux outils sont mis à disposition pour automatiser ces étapes. Le mouvement devops œuvre pour un rapprochement entre le développement et les services opérationnels pour optimiser ces processus (voir mon compte rendu de la session du Jug Lyon sur le sujet http://javamind-fr.blogspot.fr/2011/12/devops-au-lyon-jug.html).

Au niveau de la complexité des applications, la pierre peut être en partie jetée côté architectes applicatifs ou autres consultants, qui ont parfois la fâcheuse habitude de complexifier inutilement l’architecture générale d’une application. Il faut savoir rester sur des choses simples et se cantonner aux besoins immédiats (je vous conseille de lire le compte rendu Devoxx fait par Ninjasquad sur les interventions de Adam Bien et Chet Haase http://blog.ninja-squad.com/2012/11/22/devoxx/ )

Le prochain article parlera des problèmes liés au logiciel/progiciel et notamment de la multiplication des fonctionnalités non utiles aux utilisateurs

Merci à Agnes Crepet, Anne Laure Rigaudon, Alfred Almendra, et les autres anonymes pour leur relecture et leurs différentes critiques.