Nous sommes dans le domaine de l’informatique embarquée sur des terminaux de paiement, avec des flux à ouvrir vers les commerçants et vers les banques. Un élément de contexte : avant de pouvoir commercialiser une solution de paiement, il faut qu’elle soit certifiée dans le pays ou la zone où elle sera utilisée.

Le problème (le P du PDCA)

Notre équipe travaille sur un terminal de paiement nouvelle génération, considéré comme une innovation majeure pour l’entreprise. 10 jours avant la certification du terminal, les tests de performance ont révélé que les temps de réponse étaient de 1 200 millisecondes alors que la norme à atteindre était de 100 millisecondes.

1 200 millisecondes contre 100 : le cadre du problème est parfaitement clair.

Comment réagir en moins de 10 jours sachant que la correction du problème va déclencher les 533 cas de tests de non régression ainsi que la réalisation de 130 tests d’intégration ? Plusieurs établissements bancaires sont en attente de cette solution : accepteront-ils un décalage, sachant que la concurrence se presse à leur porte ?

Gemba lean software – ce qu’il fallait refaire :

Techniquement, la solution comporte du code applicatif, un kernel fourni par un prestataire externe et une mémoire flash. A quel moment du processus le temps de réponse augmente-t-il ? Deux points apparaissent lors du gemba produit :

• la mémoire flash est très sollicitée et ralentit le système ;
• nombre de triggers d’initialisation sont appelés de façon répétée et tardivement dans le processus.

Avec une exploration de type « 5 pourquoi », l’équipe découvre que certains sous-processus sont lancés trop souvent, sans valeur ajoutée. Par exemple : l’identification de la banque se fait à chaque saisie du montant au lieu de se faire durant la phase d’initialisation offline .

Maintenant que les points de cause sont précisément identifiés, pourquoi le processus de construction de la solution n’a-t-il pas permis de protéger l’entreprise de ces dérapages de temps ?

Deuxième gemba, cette fois-ci sur le processus de Build , les documents échangés, le contenu des user stories. Deux écarts aux standards apparaissent :

• Des spécifications précises ont été retrouvées dans les user stories mais elles n’ont pas intégré cette nécessité d’atteindre un certain de temps de réponse (on parle de « test d’acceptance » absent) ;
• Les développeurs connaissent les technologies sur lesquelles ils travaillent mais moins bien le domaine du paiement et notamment les bonnes pratiques génériques préconisées par les opérateurs de carte (Visa, Mastercard, EMV).

Passage à l’acte (le Do du PDCA) :

L’équipe prend alors plusieurs décisions pour améliorer le temps de réponse, dont on ne fera pas la liste. Deux exemples :

• Déplacer certaines lignes de code liées au contrôle plus en amont, ce sera l’action la plus impactante.
• Désactiver la génération des fichiers log et ajouter du cache.

L’équipe QA, en charge des 533 tests de non régression, s’est elle-aussi mobilisée pour travailler au rythme des développeurs et faire gagner du délai. Ils parlent de « pair testing programming » en référence au « pair programming », pratique agile issue de l’Extreme Programming. La solution a été livrée en certification dans les délais de 10 jours !

Finalement, l’équipe a-t-elle réussi à être à l’heure le jour de la certification (le C du PDCA)

Bien sûr, l’équipe a réalisé un check de ses actions. Résultat atteint : 97 millisecondes.

Et ensuite (le Act du PDCA)

A l’issue de cette période de forte tension, le centre de développement dans son entier a décidé de se former aux aspects les plus techniques et d’architecture du monde du paiement afin de gagner en efficacité et sérénité.

---

Vous souhaitez être accompagnés ou connaître nos offres ? Contactez-nous par email à l’adresse contact at operaepartners point com, par téléphone au 01 40 05 96 88 ou avec le formulaire ci-dessous :