La qualimétrie en Open Source, ça marche

3:27 Non classé

Ah, le vieux rêve du portail qui indique d’un coup d’oeil l’état d’avancement des projets et leurs éventuels problèmes, et auquel se réfèrent avec un égal bonheur DSI, chefs de projet, développeurs, prestataires…  J’ai vu pas mal de communication sur le sujet, mais beaucoup moins de mises en oeuvre (à ce propos, j’ai retrouvé un reportage que j’ai écrit en 2003, à la DSI Voyageurs de la SNCF : je le publie dans un prochain billet ). Quand Fabrice Bellingard, de la SSII Qualixo, m’a contacté pour me parler d’un tel projet, en Open Source cette fois, je lui ai donc dit que je voulais bien en parler (voir l’article sur LMI )… s’il me présentait un utilisateur. Voilà qui est chose faite : Thierry Bey, responsable entité Langages, Qualité et Processus de Développement de PSA Peugeot Citroën, m’a accordé une bonne heure d’entretien, ce dont je le remercie. Voici le contenu de cet entretien – en espérant que cette fois, la notion d’Open Source contribue à emporter l’adhésion de tous.

Quel cheminement vous a conduit à prendre la décision de déployer le projet Squale au sein de PSA Peugeot-Citroën ?

Nous menons depuis plusieurs années chez PSA une démarche de contrôle de la qualité des développements pour en réduire les coûts et les délais. Nous avons donc mis en place différents processus et outils nous atteindre ces objectifs. Squale s’intègre dans ce dispositif général et permet de répondre aux différentes étapes du processus quelque soit le type de projet concerné (régie, forfait…).

Des éditeurs proposent depuis plusieurs années maintenant des produits commerciaux pour maîtriser la qualité des développements internes et externes. Leurs offres ne vous satisfaisaient pas ?

Nous les avons bien sur étudiées. Souvent il s’agit de solutions onéreuses. En outre, ces produits commerciaux nécessitaient un gros travail d’adaptations pour intégrer les spécificités projets.

Comment avez-vous connu le projet Squale ?

PSA fait partie des membres fondateur du club Qualimétrie [NDLR : dont la base de connaissance sert de support aux modèles de Squale]. Les discussions avec d’autres grands comptes au sein de cette plate-forme d’échanges nous ont rapidement convaincu de l’intérêt de ce projet Open Source pour mieux maîtriser les développements.

Il était important que ce fût en Open Source ?

Oui, d’abord parce que cela élimine des coûts logiciels, et ensuite parce que cela nous donne la possibilité de mettre en place une solution qui correspond au plus juste à nos besoins. Enfin et surtout, cela nous permettait de démontrer notre capacité à développer une méthodologie innovante pour la réalisation de projets. Ce partage d’informations avec d’autres grands comptes donne de la valeur à la solution et facilite son acceptation en interne. Tout le monde est d’accord pour faire de la qualité, mais quand on regarde les contraintes que cela implique, c’est tout de suite plus compliqué. Il fallait donc une véritable crédibilité. Ce partage avec d’autres grandes entreprises partageant des problématiques similaires nous permettait d’aller vers une standardisation mieux acceptée.

Vous avez testé Squale sur une dizaine de projets pilotes. Vous avez maintenant décidé de le déployer à plus grande échelle. Comment comptez-vous procéder ?

Notre objectif est que Squale devienne une plateforme incontournable pour tous les développements dans les filières majeures. Chez PSA plus de 300 projets sont concernés. Nous avons donc prévu un « Squale tour » qui va nous permettre de faire connaître la plateforme et de la positionner au mieux en fonction des besoins des équipes projets, pour susciter l’adhésion.

Les projets de contrôle de la qualité sont parfois difficiles à faire passer auprès des équipes, qui peuvent considérer cela comme du ‘flicage’. De votre côté, au niveau du management, vous adoptez donc un mode entièrement incitatif ?

L’approche communautaire et participative de l’open source constitue un formidable accélérateur pour la qualité. Nous avons déjà procédé de cette façon avec la plateforme d’intégration continue, et c’est un pari en passe d’être gagné. Cette démarche a été initiée avec les équipes d’étude puis se diffuse par capillarité. L’adaptation et l’adoption sont progressives. Au final, je ne pense pas que cela soit perçu ni vécu comme du « flicage », mais plutôt comme un nouveau service offert pour réaliser une bonne application selon les critères de PSA.

Disposez-vous de résultats quantifiés, ou au moins d’avantages identifiés, à la suite des projets pilotes que vous avez menés ?

En ce qui concerne le ROI de la démarche, on est en train de le construire avec le club Qualimétrie. Nous constatons en interne que la démarche a permis de mieux associer les équipes, notamment les plus réticentes à ce type d’outils. Les équipes projet se sont inscrites dans la démarche plus facilement qu’avec de simples règles de développement. C’est devenu une habitude de travail. Les équipes se posent davantage de questions sur l’architecture applicative, s’écartent le moins possible des standards de développement. Pour nous, c’est l’assurance de minimiser l’impact pour l’intégration, les migrations, etc. En outre, cela facilite la capitalisation de l’expertise technique : les problèmes récurrents, vus sur plusieurs projets, sont détectés plus en amont. Aujourd’hui, les gens des équipes projets sont plutôt demandeurs, et on en a vu les effets sur les bonnes pratiques.

L’outil et la démarche sont-ils compatibles avec tous les projets (internes, externes, méthodes agiles, etc.) ?

Pour les prestataires, nous n’avons rien contractualisé pour l’instant. L’Open Source offre l’avantage de faciliter l’accès à tout l’outillage. Nous nous efforçons d’appliquer les outils et la démarche pour tout projet. Des axes d’amélioration existent et seront mis en œuvre ultérieurement. Ainsi l’on pourrait envisager un modèle intégrant des déclinaisons différentes selon la typologie des projets, le niveau de criticité…

Le temps d’appropriation par les équipes n’est-il pas un obstacle ?

L’utilisation de la solution, relativement intuitive, ne pose aucune difficulté. La mise en œuvre elle-même se fait au travers de simples échanges avec les projets. Généralement nous procédons en deux temps : d’abord nous demandons aux équipes de nous expliquer leur projet, généralement pendant une demi-journée, puis nous paramétrons Squale en fonction de ces informations. Ensuite, nous pouvons intervenir pour accompagner les projets dans leurs choix de solutions. Ce deuxième rendez-vous contribue à renforcer l’autonomie des équipes utilisatrices.

Qu’attendez-vous aujourd’hui des évolutions de Squale ? Peut-être la prise en charge d’autres langages ?

A court terme, nous pensons nous appuyer sur la capacité d’ouverture de Squale pour intégrer des notions complémentaires comme la sécurité applicative, la modélisation… afin de qualifier une application dans sa globalité. Chez PSA, nos efforts portent dans un premier temps sur les filières stratégiques, qui reposent notamment sur Java et qui offre en outre une large palette d’outils gratuits. A terme, le besoin peut s’orienter vers des langages de type PHP, .Net, Flex. Dans ce cas, le recours à des achats logiciels sera certainement nécessaire.

One Response

  1. Archive #3: démarche outillée de surveillance de la qualité des développements à la DSIV SNCF | Le Blog d'Olivier Rafal : Ingénierie Logicielle Says:

    [...] à la DSIV SNCF novembre 5, 2009 3:49 Olivier Rafal SGBD, langages & développement Suite à mon billet sur la mise en oeuvre du projet Squale au sein de PSA , je me suis souvenu du reportage que j’ai effectué à la DSI Voyageurs de la SNCF, et qui a [...]

Rédiger un commentaire

Votre commentaire

Vous pouvez utiliser ces balises: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

NB: Votre commentaire ne sera publié qu'aprs la validation du modérateur du blog. Vous n'avez pas besoin de le publier à nouveau. Merci