Les processus : plus critiques que les ressources technologiques

Si on devait présenter à un martien les processus de développement IT, on pourrait dire qu’ils sont synonymes de façon de travailler pour créer un système informatique. Mais toutes les façons de travailler ne se valent pas, et celles qui fonctionnent sont précieuses. Elles sont inventoriées et cartographiées sous forme de processus .
Bien sur des outils et langages de programmation sont des ingrédients nécessaires pour fabriquer une application. Mais ils ne sont pas pérennes, le changement technologique qui les fait naître fini aussi par les rendre un jour obsolètes. Les technologies changent de plus en plus vite, c’est leur propre, personne ne peut donc garantir qu’une technologie donnée perdurera pour répondre aux problèmes de demain.
Alors que les technologies (outils et langages IT) naissent, évoluent et deviennent obsolètes, les processus demeurent, assurant la maîtrise de la complexité des projets à réaliser.
Non seulement les processus peuvent être  perfectionnés intégrant ainsi plus de valeur ajoutée mais de plus ils sont bien plus durables que les outils de développement. En fait les processus de développement portent un savoir faire collectif  et durable. De plus, à la différence des technologies qui sont des ressources que l’on peut acheter, les processus et méthodes sont des aptitudes à faire, on ne peut en faire l’acquisition sur étagère.
De ce fait, leur développement est délicat, et prend du temps, les processus ne peuvent être confondus avec des ressources marchandes. Ce sont des formes de compétences collectives, associées à une organisation.


Quel que soit le projet informatique à réaliser, et dans tous les secteurs d’application, la maîtrise des processus permettra de répondre aux challenges posés par la complexité croissante.  Les organisations ont donc intérêt à gérer et à améliorer leurs pratiques : processus, méthodologies...qui constituent une richesse immatérielle non achetable. Voici pourquoi, en ce qui concerne le développement logiciel, de plus en plus d’efforts significatifs sont réalisés pour prendre conscience des processus, les inventorier et les cartographier et les améliorer. C’est un réel capital de savoir-faire collectif, source de prospérité.

« Je n'utilise pas ce processus dans mon projet...je ne vois pas à quoi il sert »

C’est une des résistances fréquentes au déploiement d’un processus ou d’un de ses aspects. Ce type de remarque peut apparaître lors de revues qualité ou d’audits ou de coaching. Ce type d’objection indique souvent un manque de compréhension ou de communication.
Personne n’aime obéir sans comprendre. Ici il ne manque pas de détails sur le processus ou de fonctions dans l’outillage. Non, bien au contraire, il s’agit d’une carence de communication, à un niveau relativement macroscopique, sur l’intention et les bénéfices qui justifient le dispositif décrit dans le processus. Cette objection ne doit pas rester sans réponse, car sans motivation claire des raisons d’être un changement imposé dans la façon de travailler n’est pas aisément accepté.

La réponse réside dans l’affirmation explicite de la politique interne à suivre pour ce processus, telle que décidée  par le management. Elle est parfois oubliée ou sous-estimée, mais c’est une carence aisée à corriger. Une politique interne doit démontrer la volonté du management de mettre en œuvre tel processus, mais c’est insuffisant pour faciliter l’adoption de nouvelles pratiques. Au-delà de cette marque d’autorité, la politique choisie devrait inclure les motivations sous-jacentes qui rendent le processus utile et même incontournable, ainsi que l’approche retenue dans sa mise en œuvre. L’approche c’est la façon de traiter le sujet au centre du processus, habituellement suivant quelques critères principaux.
Cette politique doit trouver sa place dans le référentiel (méthodologique ou des processus, suivant le vocabulaire adopté).C’est le sens de ce que demande la pratique GP2.1 « Etablir une directive organisationnelle ».  La formulation d’une politique confère autorité et justification au dispositif organisationnel  défini dans le processus, et c’est donc avec raison que le modèle CMMI l’exige.