De l’offshoring en Suisse : c’est possible !

Si offshoring rime souvent avec économies et court termisme, il existe d’autres raisons pour externaliser son développement logiciel. Et pourquoi ne pas venir en Suisse ? Retour sur deux expériences récentes, entre Lausanne et les États-Unis. Quels enseignements pouvons-nous en tirer au quotidien ?

Dallas et San Francisco: une startup et une entreprise biotech aux ambitions démesurées. Au Texas, une blockchain de paiements doit pouvoir démontrer disponibilité, performance et sécurité. En Californie, des laboratoires veulent pouvoir suivre le fil des analyses menées par leurs chercheurs. A Dallas comme à San Francisco, les défis IT sont à la hauteur des enjeux. Dans les deux cas, il faut rester sur le fil du rasoir, entre rapidité d’implémentation et durabilité, entre complication et complexité, entre simplification et perception des enjeux fondamentaux.

Pour ces entreprises aux moyens confortables, recruter des talents ne devrait pas être un problème. LinkedIn nous le dit : tout le monde fait de la blockchain et de l’AI, maîtrise l’UX, l’agilité, l’architecture, le Big Data, le cloud, DevOps, le software craftsmanship ! Mais en y regardant de plus près, le marché célèbre trop souvent des PoC enchanteurs mais sans lendemains, des victoires techniques mais vides de sens.

Nos deux entreprises ont mené des centaines d’interviews, recruté des cadors qui ont quitté le navire en découvrant la différence entre régate sur une fusée en carbone et course au large. Mais ces constats ne résolvent pas leur problème : l’équipage manque à l’appel.

L’offshoring haut de gamme, une solution au manque de compétences locales

Il est alors naturel de se tourner vers un prestataire. Mais si les enjeux sont clairs, les besoins sont vagues. Une externalisation classique est inadéquate : spécifications rigides, développeurs livrés au kilo, le tout orchestré par des chaînes managériales déconnectées. Désespérés, Californiens et Texans lancent des bouteilles à la mer.

Ces bouteilles s’échouent sur les rives du lac Léman, devant la porte d’OCTO Technology. Si nous intervenons sur des missions d’architecture ou de transformation agile, notre approche est toujours holistique. Nos architectes sont certes des esthètes du Post-it®, des forçats du PowerPoint, mais ils restent avant tout des techniciens et ne peuvent ignorer de tels défis. Comment ne pas mettre notre savoir-faire méthodologique et technique à l’épreuve ? Nous nous allions à un partenaire local pour monter un équipage de huit pour relever le défi texan, tandis que trois Octos surferont la vague de San Francisco.

L’agilité : une philosophie radicale et des processus dictés par le sens

L’agilité n’est pas une recette, c’est une philosophie. Il s’agit de construire un produit en mêlant valeur métier, besoin des utilisateurs, excellence technique et fluidité des opérations, tout en limitant les gâchis (mudas). Il n’est plus question de silos, mais d’une équipe mixte, autonome et responsable qui communique de manière transparente.

Avant même le démarrage de ces missions, nous posons ces préceptes comme conditions. Si tout le monde “connaît l’agile”, une dose de pédagogie est nécessaire pour des donneurs d’ordres habitués à… donner des ordres. Afin de limiter les risques, la contractualisation devient elle aussi agile: une phase de cadrage 360 puis des livraisons incrémentales.

Le cadrage consiste en une quinzaine d’ateliers concentrés sur une courte période. Il permet de s’aligner : vision, rôles et responsabilités, UX, storymap, choix architecturaux, risques, roadmap, organisation. Au delà de poser les fondations du produit, il s’agit de décider s’il est judicieux de mettre le navire à flot.

Le cadrage 360 n’est pas spécifique aux projets offshore. Cependant, la distance entre les parties lui confère un autre rôle : celui d’apprendre à se connaître et prendre ensemble le risque de se faire confiance. Les ateliers devront donc se faire de visu. Pendant deux semaines, les développeurs en profitent aussi pour s’immerger, pour acquérir des connaissances légales de base ou les grands principes du séquençage d’ARN. Réciproquement, une biologiste de découvrir les bases du développement logiciel.

Des cycles et des outils adaptés à la distance

Une fois le cadrage bouclé, l’équipe se retrouve séparée par un océan et une dizaine d’heures de décalage. Or l’agilité préconise la proximité...

Scrum, Kanban ou ScrumBan, ce choix est de la responsabilité de l’équipe. Des outils classiques servent évidemment de vecteurs de communication mais des rituels transatlantiques réguliers entretiennent la vitalité de la relation. Nous adoptons trois cycles: a) une courte session quotidienne de vidéoconférence pour faire le point sur la position et les demandes d’aide; b) une démonstration bimensuelle à distance; c) une rencontre physique bimestrielle d’une semaine, avec toute l’équipe.

De nombreux outils en SaaS existent pour accompagner l’agilité et semblent à première vue indispensables. Cependant, ces outils imposent un carcan. Après de multiples essais, tableaux blancs, murs et Post-it® ont prouvé leur supériorité. Une photo quotidienne du board, des sketches papier transportés, ne sont au final qu’un petit prix à payer.

Si le cloud s’avère un faible allié pour la méthodologie, les bénéfices sont irremplaçables pour la partie technique : code review, intégration et déploiement continu, containerisation, ressources partagées ou monitoring.

Finalement, un aspect est souvent négligé : le passage de relai. Dès la conception, un effort doit y être consacré. Plusieurs dimensions sont impliquées : a) la documentation architecturale; b) la cohérence de pratiques de développement; c) des tests unitaires automatiques exhaustifs et plus ciblés au niveau système (e.g. chaos, performance); d) l’automatisation des opérations. Nous encourageons aussi nos clients à participer aux décisions techniques et à conduire des audits réguliers.

“Peu importe le problème, c’est un problème de personnes” (Gerald Weinberg)

Deux écueils récurrents se profilent sur la route d’un projet agile et sont exacerbés par la distance et la relation client/prestataire.

Le premier danger apparaît lors de la contractualisation d’un produit en mode agile. S’il est clair que des spécifications explicites ne servent pas de base à la relation, il est tentant de construire une ”feature factory” qui produit chaque semaine des fonctionnalités, mais perd de vue la finalité. L’agilité offre certes la possibilité de pivoter, mais nul ne doit oublier que des cycles plus longs (vision, roadmap trimestrielle) servent de boussole à l’équipe et de référentiel global.

Le second danger vient de l'asymétrie trop fréquente entre client et prestataire ou entre métier et IT. Si de tels rapports délétères existent dans certaines organisations, notre conviction est qu’ils sont incompatibles avec l’agilité. Nous préconisons alors de gommer les différences de traitement (e.g. conditions de voyages, visibilité), et d’organiser des événements pour souder l’équipe. Matchs de NBA, soirées, concerts au Montreux Jazz, villa au bord de la plage peuvent sembler des dépenses extravagantes, mais elles ne représentent qu’un coût marginal et s'avèrent vite rentables.

Dans un article sur l’offshoring, nous ne pouvons faire l’impasse sur les “différences culturelles”. Elles existent, certes, et se voient souvent accusées de tous les maux. Il s’agit, à notre avis, d’un poncif éculé qui cache mal une forme de néocolonialisme et tente d’excuser des dérives. Notre expérience nous a montré, sur de multiples dispositifs, comment elles ont pu être circonvenues en prenant un peu de hauteur sur les relations humaines.

Quels enseignements en retirer ?

L’offshoring en Suisse est-il un business model pérenne ? Non. Cependant, ces projets sont riches en enseignements. La distance nous a poussés à mettre encore plus en exergue la discipline et la confiance, ciments de la philosophie agile. Et que la distance soit de dix mètres ou 10’000 kilomètres, les problèmes qui émergent sont du même ordre.

Ces projets phares battent aussi en brèche un certain sentiment d’infériorité helvétique. Il existe bel et bien un savoir faire IT dont nous n’avons pas à rougir. Pour finir de se rassurer, il est troublant de voir le piédestal sur lequel la Suisse est mise dans la Silicon Valley, mélange de clichés mais aussi de rayonnement mérité. Et qui aurait dit que la Suisse deviendrait un terreau pour la course au large ?

Finalement, la pénurie mondiale des talents dans l’IT nous a offert la possibilité de participer à des projets passionnants et d’y prendre du plaisir. Mais cette pénurie généralisée peut être une occasion unique de rebattre les cartes culturelles, de voir quelles organisations sont prêtes à évoluer et abattre les murs entre “métier” et “IT”.

Cet article a été publié dans la version papier du journal ICT, en mai 2019