« S’affranchir du cycle en V » « Agile canada dry » ou comment perdre 4 ans et 1.45 M€

Alors qu’elle était plaignante, la société d’assurance Macif vient d’être condamnée à payer à un éditeur de logiciel 1.45 millions d’euros pour la résiliation abusive d’un contrat d’intégration après plus de trois ans de procédure.
Un exemple de plus de transformation « agile » canada dry, qui trouve son origine dans des incompréhensions majeures maintes fois décrites (iciici ou ). Claironner que l’on « fait de l’agile » car il est prévu (dans un contrat !) de mettre en place un cycle de développement « itératif »mais tout en gardant toutes les rigidités d’une approche waterfall mène au désastre.

Petit rappel chronologique :
2012
*Mai : la Macif souhaite remplacer l’application informatique de gestion d’activités d’assurance jugée obsolète. Elle lance un appel d’offre, qu’un éditeur emporte.
*Juillet-Décembre : phase de cadrage réalisée par l’éditeur pour « préciser le périmètre fonctionnel »

[jusque là du très classique, tout va bien. Prendre 6 mois pour faire une « vraie » phase de cadrage est même plutôt bon signe à ce stade]

2013
*Février : signature d’un contrat d’intégration : une  annexe indique qu’une « méthodologie est convenue prévoyant des ateliers de conception itérative et progressive pour aboutir à la rédaction de spécifications fonctionnelles détaillées (SFD) devant être validées, phase préalable à leur transcription dans la solution logicielle ».

[aie aie aie ça commence à sentir mauvais : mettre en place des « ateliers de conception itérative et progressive » (ça c’est pour « faire agile ») mais qui ont pour finalité de livrer un document de spec détaillées figé et exhaustif (ça c’est « cycle en V« ) est pour le moins questionnable]

*Mars-Octobre : après de multiples retards et reports, la Macif met finalement en demeure l’éditeur de livrer « l’ensemble des spécifications fonctionnelles détaillées ». Celui-ci s’exécute mais considérant que l’éditeur n’avait pas respecté le délai imparti et que la livraison ne couvrait pas la moitié des besoins exprimés, la Macif résilie le contrat. 

[le crash : on imagine 8 mois d’échanges de mails menaçants, de conf call bien saignantes, de réunions « de la dernière chance » qui n’aboutissent à rien, pour finir par des lettres recommandées entre avocats. La conception collaborative « itérative et progressive » est décédée depuis longtemps. « L’application informatique de gestion d’activités d’assurance jugée obsolète » à remplacer est surement toujours là, les utilisateurs au mieux exaspérés, au pire résignés]

2016
*Juin : la Macif est finalement condamnée par le tribunal de commerce, à ses seuls torts. Dans la décision, le terme « agile » n’est pas directement cité mais un passage y fait référence en utilisant une formule savoureuse

« les parties se sont affranchies de la méthode du cycle en V« 

Tout le débat juridique a tourné sur la notion de spécification fonctionnelles détaillées (les fameuses SFD, un livrable typiquement estampillé cycle en V) et le fait de savoir à partir de quand elles sont suffisamment « détaillées » et « précises »: on imagine les crises de nerfs face à des débats sans fin : qui est vraiment responsable de les produire ? de les valider ? à quel moment ? à partir de quel degré de « précision » sont elles « valables »  ? comment et par qui est appréciée la notion de « validité », le degré de « précision » ?
Dans un mode cycle en V bien rigide, les réponses à ces questions sont à peu prêt claires (ce qui ne veut pas dire que ça fonctionne bien pour autant) mais en voulant plaquer des principes de « développement rapide » sans remettre en cause tout le reste et surtout sa culture de gestion de projet basé sur une stricte contractualisation, la Macif s’est complètement fourvoyée. Devant un tel flou, le tribunal a considéré que

la spécification des besoins a été effectuée à partir d’une méthodologie dite de développement rapide (RAD), basée sur une démarche itérative entre la maîtrise d’ouvrage et le maître d’oeuvre, impliquant que les concepteurs fonctionnels et les représentants des utilisateurs définissent ensemble l’application lors des ateliers de conception, et conduisant à ce que la configuration du progiciel se stabilise progressivement et continue à évoluer assez tardivement dans le projet

au final, la conclusion est limpide et implacable :

le défaut de qualité ne pouvant être exclusivement imputable à [l’éditeur] et l’absence de qualité des spécifications étant insuffisamment justifiée selon les différentes méthodologies suivies, le grief ne sera pas retenu contre lui.

Que retenir de cette triste affaire ?

*Les termes « itératif » et « progressif » sont surement devenu des gros mots à la Macif. Ceux qui ont trempé dedans sont partis ou placardisés, ceux qui restent sont tétanisés et plus personne n’ose proposer de remettre en cause le cycle en V. C’est toute la démarche « agile » qui s’en trouve décrédibilisée auprès du top management pour des années : quel dommage, quel gâchis.

*Comme l’indique un avocat

Les méthodes « agiles » de développement rebattent les cartes en cas de litiges informatiques. En effet, les responsabilités de chaque partie sont moins marquées, la collaboration constante rendant difficile l’imputation d’une action à l’une ou à l’autre.

Je rajouterais que « difficile » est un euphémisme, l’adjectif « impossible » me semble plus approprié. Au-delà, c’est donc surtout la notion même de contrat « au forfait » qu’il s’agit de questionner: vouloir « être plus agile » et continuer à exiger de ses prestataires un engagement au forfait (dans lequel on tente souvent de lui faire porter seul le risque) est antinomique.

*Vouloir être agile ET établir dès le début une relation de défiance véhiculé par un message négatif (« on a encore rien commencé mais je pense déjà que ça va mal se passer => je me protège par un contrat pour que ce soit l’Autre qui soit désigné comme responsable le jour où ça va (forcément) déraper ») fonctionnera très mal. Cela ne signifie pas qu’il ne faille rien contractualiser, mais plutôt d’inventer un autre mode de contractualisation.

*Gérer un projet en cycle en V n’est pas une mauvaise chose en soi, certains contextes s’y prêtent très bien ! Mais il s’agit d’être cohérent : soit on reste sur une méthodo cycle en V, on assume ses défauts et limites, on exige un engagement au forfait, on le contractualise. Soit on veut aller vers plus d’agilité, on sait pourquoi, mais dans ce cas, il faut remettre en cause aussi le pré requis « blinder ça dans un forfait sinon ce n’est pas sérieux ».

La thématique de la contractualisation agile est un sujet brûlant débattu depuis des années (ici, ici ou  par exemple), un modèle de contrat open source est même proposé depuis 2011 par Xebia , mais pourtant il encore très loin d’être épuisé. C’est certainement le point le plus complexe et difficile d’une transformation agile pour les organisations qui ont massivement sous traité leur IT depuis des décennies et dans lesquelles la culture du clivage MOA/MOE (qu’il s’agit précisément d’abandonner quand on souhaite aller vers plus d’agilité) est le plus ancrée. Il est intéressant de noter d’ailleurs que cette difficulté n’existe pas pour les géants du web qui eux ont privilégié dès leur création le build en interne, faisant d’eux des « agile natives ».

*L’enjeu numéro 1 d’une transformation agile n’est pas une question de méthode mais de changement d’état d’esprit et de culture : les 2 parties qui s’apprêtent à travailler ensemble sont elles prêtes à se faire (vraiment) confiance ? Un bon chef de projet, est ce celui qui va le mieux arriver à imputer les problèmes à son prestataire ?

 

 

 

Advertisements

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s