L'itération agile : entre SSII et agence, un nouveau mode de prestation informatique

Alors que la plupart des sociétés de service informatique (SSII) essaient de vendre le plus de jours.homme possible, marmelab a choisi de vendre un package plus ambitieux : l'itération agile. Il est aussi plus risqué. Qu'est-ce qu'il contient ? A qui s'adresse-t-il ? Et est-ce que ça marche ? Réponses.

La régie informatique en France: le jour.homme

Beaucoup de SSII françaises vendent avant tout du "jour.homme". Cette unité d’œuvre correspond à une obligation de moyen pure sur un projet dont la direction est entièrement assurée par le client. Ce mode d'intervention, couramment appelé "régie", a pas mal d'inconvénients :

• la gestion des missions des consultants est confiée à des commerciaux, dont le principal objectif est d'allonger la durée de mission le plus longtemps possible pour maximiser le nombre de jours.homme
• la société de service n'a pas d'intérêt à fournir des consultants qui collent au besoin. La réussite du projet client n'étant pas un facteur direct de succès, "caser" un développeur PHP débutant sur un projet Java complexe, c'est quand même augmenter son chiffre d'affaire
• l'évolution et la formation des consultants sont conditionnées au bon vouloir des clients. Intéressé par ES6, Go et Swift? Pas de chance, votre client ne fait que du PHP, on en reparle dans deux ans
• le consultant fait davantage partie de la société cliente que de la société de service. D'ailleurs, beaucoup finissent "chez le client", qui n'a d'autre choix que de les embaucher puisqu'ils deviennent indispensables et que la loi interdit de les garder en prestation plus de 3 ans. Conséquences : turn-over et dilution de la culture de la société prestataire.

Je ne souhaite pas dénigrer ici le mode régie. S'il a des inconvénients, il répond avant tout à une demande des clients de renfort d'équipe ponctuel, et de flexibilité. De plus, beaucoup de SSII font des efforts importants pour contrebalancer ces inconvénients.

Quels indicateurs de succès?

Ces problèmes viennent à mon sens du fait que client et fournisseur ne partagent pas le même indicateur de succès en mode régie. Une mission réussie, pour la société cliente, est un projet mis en production et bien accepté par les utilisateurs. Une mission réussie, pour une SSII, est une mission longue, qui rapporte beaucoup de chiffre d'affaire.

Aligner complètement les critères de succès de la société cliente et de la SSII revient au modèle de l'agence : un engagement de résultat sur la base d'un cahier des charges, "au forfait". Mais ce modèle-là a aussi bien des inconvénients, le plus important étant qu'il n'est absolument pas compatible avec un pilotage agile des produits et des projets.

Et si on réinventait un modèle d'engagement plus proche de celui de l'agence, mais avec la souplesse de la SSII, et compatible avec l'agilité ? Un modèle qui inclurait, dans ses indicateurs de succès, le bien-être des développeurs et la faiblesse du turn-over ?

L'itération agile

Marmelab expérimente depuis deux ans un produit que nous appelons l'itération agile. Il s'agit d'un package tout-en-un qui comprend:

• 20 jours de développement par 2 développeurs full-stack dédiés
• un pilote agile (scrummaster) à mi-temps
• en option, des journées de design, d'ergonomie, ou de proxy product owner
• un ensemble d'outils projet en SaaS (Trello pour les user stories, Basecamp pour les discussions, GitHub pour le code, Travis pour la CI, BrowserStack pour les tests navigateurs)
• l'hébergement de préproduction des produits développés (sur AWS)
• un engagement de résultat par itération sur la base du backlog chiffré par les développeurs

Cette itération dure 2 semaines, et est réalisée dans les locaux de marmelab. Nous effectuons la démo et la rétrospective toutes les deux semaines chez le client.

Cette formule convient seulement à une petite partie des besoins de développement. L'itération agile s'applique au développement de produits complets, ou de nouvelles fonctionnalités d'un produit. Elle ne s'applique pas à des briques techniques pures, sur lesquelles la dépendance à d'autres briques et le manque d'indicateur de succès liés à la satisfaction de l'utilisateur empêchent l'engagement au résultat.

Nos clients nous achètent en moyenne entre 4 et 10 itérations par produit. Si un produit nécessite davantage d'itérations, c'est en général parce qu'il y a une phase de passage de relais avec une équipe technique interne. S'il s'arrête avant, c'est que les critères de succès du produit n'ont pas été atteints - soit parce que l'équipe marmelab n'a pas été assez bonne, soit parce que le produit n'était pas réaliste.

En prenant l'analogie de la restauration, il me semble qu'on achète une itération agile comme on commande un repas dans un restaurant, là où on achète de la régie comme on choisit des pâtes dans un supermarché (note: j'adore les pâtes).

Avantages

L'itération agile offre plein d'avantages sur le mode régie :

• la société cliente partage ses critères de succès produit avec les développeurs, ce qui favorise l'engagement
• la responsabilité du succès et de l'échec n'est pas diluée au sein d'une équipe de consultants de sociétés différentes : elle est identifiée par feature, et par équipe
• le pilotage agile du projet (SCRUM) et du produit (Lean Startup) sont possibles
• on peut s'engager sur le résultat de chaque itération. Si le résultat n'est pas atteint, le projet s'arrête. La prise de risque est donc partagée entre la société cliente (qui risque du budget perdu) et la société prestataire (qui risque de la précarité)
• les développeurs étant toujours en binôme, les meilleures pratiques de développement agile (revue de code, propriété collective du code, automatisation des tests et des déploiements) sont mises en œuvre. Et les développeurs apprennent en permanence de leur binôme (qui change à chaque mission)
• les missions sont courtes, et les consultants apprécient la variété des sujets traités. Si les missions sont plus longues, et que les consultants se lassent, rien n'empêche de changer la composition de l'équipe... tant que l'objectif de chaque itération est atteint
• comme il s'agit souvent de features ou de produits isolés, l'architecture de la solution technique s'oriente naturellement vers des microservices, et les technologies utilisées sont moins contraintes. Les développeurs peuvent donc utiliser des technologies plus variées (chez marmelab: React.js, Angular.js, Node.js, Symfony, Go, PostgreSQL, ElasticSearch, RabbitMQ, etc...)
• l'équipe agile sert souvent d'ambassadeur de l'agilité chez le client. Car les projets en itération agile donnent des résultats très vite, s'adaptent aux nouvelles contraintes en quelques semaines, et s'arrêtent très vite aussi lorsqu'on atteint une impasse. Les autres équipes de la société cliente sont souvent convaincues des bienfaits de l'agilité, par l'exemple.

En fait, l'itération agile fait passer le sous-traitant au statut de partenaire. C'est une relation plus gratifiante pour les deux parties, mais aussi plus exigeante.

A moindre coût

Ce mode d'engagement nécessite des profils (développeur et scrummaster) polyvalents et expérimentés. Ces profils sont très difficiles à recruter, encore plus difficiles à garder. Ils sont donc en général très chers. C'est pourquoi l'itération agile est souvent vue comme un produit haut de gamme.

Et pourtant, le prix de l'itération agile marmelab est agressif (environ 20% en-dessous des prix du marché). Vous voulez la recette ?

Le pari de marmelab, c'est de satisfaire les besoins de clients majoritairement parisiens par une prestation réalisée majoritairement en province. En province, les rémunérations IT (et le coût de la vie) sont 20% à 30% inférieures à ce qu'elles sont sur Paris. En payant des développeurs 15% de moins qu'à Paris, on peut attirer les meilleurs, leur assurer un bon niveau de confort, tout en maintenant des prix très compétitifs pour nos clients parisiens.

Ça ressemble au modèle de l'off-shore, mais il y a beaucoup de différences. D'abord parce que l'off-shore a de nombreux coûts cachés dus aux différences culturelles. D'autre part, la distance est un fort facteur de ralentissement dans l'off-shore. Les consultants de marmelab, eux, sont en France, à 1h30 de leurs clients, viennent les voir toutes les deux semaines, et peuvent faire l'aller-retour à Paris dans la journée en cas de souci.

Ce pari repose aussi sur un constat : même si les projets les plus ambitieux sont souvent issus de clients parisiens, il y a énormément de talents en province. Ayant travaillé quinze ans à Paris, je connais le snobisme des sociétés parisiennes, qui sont persuadées que les meilleurs développeurs sont dans la capitale. Croyez-moi, c'est une illusion.

Marmelab arrive donc à être compétitif en faisant le lien entre des besoins parisiens et des talents en province. Ce n'est pas de l'off-shore, pas non plus du near shore. J'appelle ça le rural shore.

Enfin, un prix est un positionnement, un acte volontaire. Nous avons fixé le prix de l'itération agile marmelab volontairement bas pour nous permettre de disposer d'assez de demandes, et de pouvoir choisir celles qui collent le mieux à nos compétences. C'est moins rémunérateur, mais on s'épanouit davantage.

Ce n'est pas facile

Malgré tous ces avantages, le package "itération agile" n'est pas facile à vendre. Le partage des risque sur lequel il repose n'est pas encore entré dans les mœurs. Il présuppose que la société cliente soit prête à déléguer le pilotage d'une partie de son projet. La société doit accepter que les prestations ne soient pas développées dans ses locaux.

La contractualisation de ce mode agile est également toujours un sujet de débat avec nos nouveaux clients. Obligation de résultat, de moyen ? Pénalités de retard, prise en compte des journées d'absence ? Les Directions Juridiques regardent parfois nos contrats comme des OVNI, habitués qu'ils sont aux contrats de SSII standardisés.

De nombreuses sociétés clientes nous appellent toujours pour nous commander des journées de prestation technique. Ce sont souvent des Directions de Systèmes d'Information (DSI), qui recherchent avant tout des "ressources" maîtrisant Symfony, Node.js, Angular. Si nous répondons parfois positivement, c'est surtout l'itération agile que nous essayons de pousser, car elle apporte plus de satisfaction aux deux parties. C'est pourquoi la plupart de nos clients sont plutôt des Direction Innovation, ou des Direction Métier, qui recherchent avant tout une capacité à faire, un partenaire prêt à s'engager à leur côtés.

Est-ce que ça marche ?

Le modèle de l'itération agile est-il pertinent ? Dans une certaine mesure, il semble que oui. Marmelab vend ce produit depuis maintenant deux ans et demi, nos clients sont fidèles, et nos collaborateurs aussi. La société est profitable, sans atteindre les niveaux de rentabilité des SSII.

Mais ce modèle ne résiste probablement pas à une croissance forte. S'il est courant de voir des SSII de plusieurs milliers de personnes, je doute qu'un atelier de développement comme marmelab puisse dépasser quelques dizaines de collaborateurs. C'est dû au fait que les missions sont courtes et en binôme, et ça rend la gestion des plannings particulièrement ardue. C'est également dû à l'investissement nécessaire pour maintenir les équipes de réalisation à un niveau d'expertise et d'engagement forts : hack days, conférences, et projets internes représentent un coût non négligeable. Et comme le package itération agile inclut une prestation de pilotage de projet technique (au travers du scrummaster), et que ce profil est encore plus difficile à recruter que celui de développeur full-stack, la croissance est forcément lente.

Ce n'est pas grave. On peut rester petit et travailler sur des produits fabuleux, en bonne entente avec ses clients.

L'itération agile met l'accent sur la force du collectif, sur la collaboration, sur le partage des clés du succès. Elle nous permet de nous éclater dans notre métier. Et ça, ça n'a pas de prix.