La question du sourcing ou du lieu de production, dans le logiciel, est celle que l’on pose en premier lieu à celui qui dit mener une recherche en diminution de ses coûts opérationnels.

De son côté, Il y a bien longtemps (en fait bien avant de songer à délocaliser) que l’industrie s’est posée des questions visant à réduire les coûts de production. Elle l’a toujours fait en fait, grâce à des services méthodes et études adaptés, en portant la réflexion sur l’ordonnancement des tâches, sur la gestion de sous-ensembles plus ou moins faciles à manipuler, mais aussi par la sous-traitance d’opérations spécifiques…

Puis sont venues les crises de surproduction industrielle des années 80 et 90. Beaucoup pour survivre, en particulier dans l’automobile, ont intégralement repensé la productivité :

– soit en considérant que le design était lui-même un facteur de productivité (Ford Ka et Focus par exemple, dont le design pourtant original est parti des formes les plus faciles à produire)

- soit en cherchant à réaliser des économies fiscales et sociales par la délocalisation

Au confluant des deux stratégies se niche la Logan de Renault. Renault a en effet imaginé un design partant d’anciennes presses et moules existants en même temps qu’il a lancé sa production en Roumanie. Mieux encore, plutôt que de partir d’une méthode up to date en occident, Renault a décidé d’oublier l’ultra robotisation et de lui préférer un vaste recours à la main d’œuvre locale, particulièrement peu onéreuse. On pourrait craindre pour la qualité du résultat… non, une Logan est une voiture solide mais qui est basée sur des matériaux un peu moins chic que d’autres productions portant des marques plus prestigieuses que Dacia.

Dans notre secteur d’activité, franchement, la réflexion sur la méthode de production laisse à désirer. J’irai presque jusqu’à dire, qu’en dehors des méthodes de gestion de projet, elle n’existe pas. C’est triste du point de vue de l’ingénieur mais ça l’est aussi du point de vue général de la performance économique : micro économique (au niveau de l’entreprise qui produit du logiciel) ainsi qu’au niveau macro économique (état producteur de logiciel).

Aussi, et un peu tout à trac, je livre quelques éléments mis en œuvre ici ou là, y compris chez nous, et qui pourraient être structurés dans une vraie analyse de la valeur (valeur travail, bien sûr ) :

- 1. faire réellement démarrer les projets par une phase de préparation

- 2. assurer l’inventaire et le suivi réguliers des fonctions et sous ensemble déjà réalisés dans le passé

- 3. concevoir autour de ces sous-ensembles quand c’est possible

- 4. choisir la technologie la moins coûteuse et la plus adaptée en fonction des points 2 et 3 (quand le client nous laisse le conseiller sur cette question)

- 5. Faire rédiger, par les testeurs, les documentations utilisateurs à partir des analyses fonctionnelles, techniques et des cahiers des tests. A la clef, il y aura réduction des coûts (en tous cas en offshore), spécialisation fonctionnelle et amélioration de la compréhension par le développeur qui disposera d’un document supplémentaire

- 6. Faire directement des PA après la réalisation des tests, alors que les développeurs sont toujours mobilisés

- 7. Ne pas hésiter à écarter des PA

Franchement qui peut penser que la qualité en pâtirait ?

La liste n’est pas exhaustive, car je n’ai pas l’intention d’aller plus loin dans ce billet. Mais je vois beaucoup d’autres idées à développer sur lesquelles Pentalog reviendra. En particulier, nous avons une idée autour d’un mode de contractualisation visant à transformer une régie délocalisée en forfait lorsqu’un ensemble livré, ayant subi un process de QA reçoit un visa. Nous y reviendrons, car cette idée s’inscrit dans la même ligne de recherche de compétitivité opérationnelle.