Ainsi pour l’installation d’un environnement de test la solution consiste souvent à récupérer des données de production. Je ne peux que donner raison à cette pratique qui permet de construire des jeux d’essais à partir de cas réel, de disposer d’un volume conséquent d’informations en un minimum de temps, et de permettre au métier de retrouver ses cas à problèmes.

Pourquoi donc changer cette façon d’opérer qui semble satisfaire tout le monde ?

Deux raisons viennent militer pour une modification :

1. les équipes de développement sont de plus en plus éclatées. Ainsi une partie de l’équipe se situe-t-elle peut-être à l’extérieur, voire à l’étranger, voire chez un sous-traitant d’un sous-traitant. Et ils ont tous besoin des moyens de tester ce qu’ils produisent. La maitrise des individus accédant aux données est donc de plus en plus difficile. D’où la question de mon titre : a-t-on besoin de laisser les clés de la maison à l’artisan venant repeindre la façade ?

2. Les exigences des instances nationales et internationales en termes de protection de la sphère privée ont évoluées, et il n’est plus possible de laisser se balader dans la nature des informations nominatives et/ou sensibles. Il est vrai que jusqu’à présent les cas de divulgation, d’utilisation frauduleuse ou d’espionnage n’étaient pas légion, mais chacun de ces risques est présent. Et probablement beaucoup d’autres.

Il faut donc revoir notre façon de construire des environnements de test. Pour cela je propose une approche simple basé sur deux postulats :

• les meilleures données de test sont les données réelles (ou de production) et il faut chercher à s’en éloigner le moins possible

• le respect de la réglementation est une obligation, celui des standards et des normes est bienvenu

N’étant pas adepte du bazooka pour chasser la souris, il me semble approprié de commencer par identifier les risques, c’est à dire le dommage que pourrait causer la divulgation ou l’exploitation d’une donnée, ainsi que la probabilité que ce dommage survienne (lié notamment à la difficulté et au matériel nécessaire pour réaliser un recoupement d’information).
Ensuite une stratégie d’anonymisation peut être élaborée afin de couvrir ces risques que l’on aura préalablement hiérarchisés.

La mise en place d’un quelconque outil n’intervient qu’en suite, et tout investissement dans ce domaine doit être lié aux dommages possibles, et non pas à un quelconque challende technique.

Pour éviter d’être trop long je propose de présenter prochainement nos vues sur le sujet, avec une démonstration sur un cas d’école, dans le cadre d’un Mardi Gras au mois de septembre.

• Une spécification exhaustive avant le début des développements est la clef du succès d’un projet
• Pour aller plus vite il suffit d’ajouter des ressources … humaines
• La productivité d’une société d’outsourcing se mesure au coût de ses ressources et non sur le ROI (politique du moins-disant)
• Le client doit spécifier en amont l’ensemble de ses besoins
• Le principal canal de communication sont les spécifications
• La taille des projets dépasse allègrement la limite maximum conseillée par le Standish Group des 6 mois / 6 hommes (Ce qui ne veut pas dire qu’on n’a pas le droit de faire 5 projets de 6 mois / 6 hommes en parallèle)
• Une fois que les spécifications ont été envoyées avec accusé de réception, c’est le problème du fournisseur que de livrer dans les temps ce qui lui ai demandé.
• …

Mais il est possible de faire de l’outsourcing sans tomber dans ces travers et c’est d’ailleurs ce que s’emploie à faire la SSII russe StarSoft basée à Saint Petersbourg. J’en parle d’autant plus librement que nous avons rencontré le dirigeant de StarSoft : Nick Puntikov qui m’a largement convaincu sur l’authenticité de sa démarche agile. Je fais ce petit clin d’oeil à StarSoft car un article intitulé ‘Agile Development On a Fast Track’ vient de paraître sur le magazine Global Service. Cet article est en fait un retour d’expérience d’un client de StarSoft : ScriptLogic sur l’utilisation des méthodologies agiles sur un projet d’outsourcing. On peut regretter dans cet article l’absence notable d’information sur l’impact profond qu’induit l’adoption d’une approche itérative sur les aspects contractuels.