Plateforme eCommerce
réinventée.
Zéro défaut critique.
9 milliards au jeu.

Une plateforme eCommerce B2B majeurement fonctionnait depuis plus de six ans. Elle traitait des milliards de dollars en transactions chaque année. Ses deux applications centrales approchaient d'une migration critique impliquant une réécriture technologique complète, une refonte d'intégration SAP et des améliorations fonctionnelles en parallèle. TechSparq a été engagé pour en orchestrer la livraison.

Ceci n'est pas une histoire de découverte stratégique qui a changé le cours du projet. C'est une histoire d'exécution rigoureuse quand 9 milliards de dollars sont en jeu et quand les partenaires de taille plus grande ont échoué à livrer sans défauts critiques.

La plateforme et les enjeux réels

Les deux applications que TechSparq devait livrer n'étaient pas des projets pilotes. Elles avaient fonctionné en production pendant plus de six ans, portant les opérations eCommerce critiques de Nike. La plateforme qu'elles constituaient était responsable de 9 milliards de dollars en revenus annuels.

La portée de la migration était substantielle. Livrer deux applications depuis une architecture technologique héritée vers une architecture moderne. Mettre à jour l'ensemble de la pile de dépendances techniques. Réécrire l'intégration SAP BAPI pour la compatibilité avec l'environnement cible. Livrer plusieurs améliorations fonctionnelles en parallèle à la migration. Tout cela sans interruption des opérations commerciales en cours.

Les attentes du client étaient enracinées dans l'expérience. Les migrations précédentes de cette envergure avaient typiquement produit sept à dix défauts critiques dans les quatre premières semaines en production. Ce n'était pas une anomalie. C'était la norme secteur pour ce que les autres partenaires de Nike avaient livré.

Le défi technique. La découverte qui a comprimé le calendrier.

Migrer une architecture applicative vers une plateforme moderne est un changement substantiel. Les applications existantes étaient construites sur une pile technologique ancienne avec de nombreuses dépendances accumulées au fil de six années. Mettre à jour cette pile simultanément avec un changement de plateforme applicative et la livraison d'améliorations fonctionnelles crée un risque composé à chaque couche.

L'intégration SAP ajoutait une dimension qui ne pouvait pas être planifiée. L'une des deux applications était profondément intégrée aux systèmes SAP et exigeait une technologie BAPI pour cette connexion. Pendant le développement, l'équipe a découvert une incompatibilité critique. Les versions du code BAPI existant et de l'environnement cible n'étaient pas compatibles par mise à jour incrémentale. Une réécriture SAP BAPI complète était requise.

Ce genre de découverte au milieu d'une migration sur une plateforme générant 9 milliards de dollars est précisément où les projets commencent à glisser les délais, où les équipes demandent des réductions de portée et où les cabinets avec moins de profondeur technique commencent à faire des compromis sur la qualité. L'équipe TechSparq l'a résolu sans heures supplémentaires et sans impact sur la chronologie.

Le modèle d'équipe distante. Ce qui l'a rendu possible.

L'engagement a été staffé de façon maigre. Un chef de projet. Un développeur Java principal. Un développeur Java senior. Un développeur Oracle. Un responsable de programme et relations. Le lead voyageait au site client environ une semaine par mois. Le reste de l'équipe fonctionnait depuis le centre de développement TechSparq.

Ce point mérite la pause. Les clients de cette envergure sont accoutumés aux grands modèles de staffing des gros cabinets de conseil. Des équipes qui créent l'impression visuelle d'effort par la taille et la présence physique. TechSparq fonctionnait avec une équipe distante disciplinée qui exigeait un soutien client minimal et une direction très limitée. Le résultat a été reconnu en interne chez Nike comme le modèle pour comment les projets de cette envergure devraient fonctionner.

Le modèle d'équipe distante fonctionne quand l'équipe a la profondeur technique pour opérer indépendamment, la discipline de processus pour rester synchronisée à distance et les standards de communication pour exposer les problèmes avant qu'ils ne deviennent des blocages. Il ne fonctionne pas quand les équipes nécessitent une supervision constante ou quand le management de projet doit compenser pour des faiblesses techniques. Cette équipe n'avait aucune faiblesse à compenser.

Le résultat obtenu. Ce qui parle sans équivoque.

Les applications migrées ont été livrées à la date et au budget. Aucune heure supplémentaire requise. Et dans les quatre premières semaines en production, deux défauts non critiques ont été découverts. Pas sept. Pas dix. Pas un seul défaut critique. Deux problèmes non critiques sur une migration B2B majeure impliquant une réécriture SAP BAPI complète, un changement de plateforme applicative et une mise à jour technologique complète d'une base de code datant de plus de six ans.

Ce résultat n'a pas fait surface parce que le projet était simple. Il a fait surface parce que l'équipe qui l'exécutait avait la profondeur technique suffisante pour trouver les problèmes pendant le développement plutôt que de les laisser remonter en production. C'est la différence entre une équipe qui code et une équipe qui conçoit.

La question structurelle. Pourquoi la différence existe.

La question de Shane Guenes, pourquoi TechSparq peut livrer ce que les partenaires plus gros ne peuvent pas, mérite une réponse directe. C'est une question structurelle, pas rhétorique.

Les gros cabinets apportent des ressources significatives. Ils apportent aussi de la surcharge. Des couches de management de projet. Des équipes avec des capacités techniques inégales. Des modèles de gouvernance optimisés pour protéger le cabinet plutôt que de livrer le résultat. Quand la qualité d'exécution baisse, ce n'est rarement parce que le cabinet manquait d'esprits brillants. C'est parce que ces esprits ont été enterrés sous des processus ou parce que l'équipe qui a gagné le contrat n'était pas l'équipe qui exécutait le travail.

TechSparq fonctionne différemment. L'équipe qui énumère la portée est l'équipe qui exécute le travail. La profondeur technique est authentique et traverse l'équipe entière, pas juste le lead. La discipline de processus et la capacité d'exécution distante ne sont pas des points de présentation. C'est comment nous fonctionnons. Et quand quelque chose d'inattendu émerge au milieu du projet, comme une réécriture SAP complète, il n'y a aucune couche de management entre le problème et les ingénieurs le résolvant.

• ■
  La profondeur technique surpasse la taille. Une équipe maigre avec expertise authentique surpassera une grande équipe avec capacité moyenne sur toute migration complexe.
• ■
  Les équipes distantes peuvent surpasser les équipes sur site. La présence physique n'est pas un substitut pour la qualité. La discipline de processus et les standards de communication déterminent le résultat, pas la géographie.
• ■
  Les taux de défaut sont un choix. Sept à dix défauts critiques en quatre semaines n'est pas inévitable. C'est ce qui arrive quand la qualité est traitée comme un problème de test plutôt que comme un standard d'ingénierie.
• ■
  Les surprises ne justifient pas les glissements. Une réécriture SAP découverte en cours de migration est significative. C'est aussi quelque chose qu'une équipe techniquement capable absorbe et résout sans impact sur délai ou budget.