La mutation des contrats de développement

Cela fait bientôt 10 ans que nous accompagnons et réalisons des projets informatiques. Un parcours riche et enthousiasmant qui nous a fait travailler sur des projets aux typologies multiples. 10 ans de conseil, de recherche et de co-conception qui nous ont transformé en véritable "partenaire technique" de nos clients. Chez Wanadev, l'innovation est au cœur de notre ADN et nous incite à constamment repenser notre forme d'engagement technique mais aussi méthodologique. Le contrat est l'un de ces jalons. Explications.

On ne fait plus un projet web comme il y a 15 ans.

Avec le temps et dans un contexte concurrentiel, les projets embarquent de plus en plus de technologies et traitent des sujets toujours plus complexes. On ne fait plus un projet web comme il y a 15 ans !

Enthousiasmant me direz-vous ? Évidemment, comme nous l'expliquions dans l'article des 9 ans de Wanadev, notre croissance s'est construite sur des challenges techniques. Elle est l'essence même de notre travail au quotidien.

@ Au-delà de cet engouement technique, les projets sont devenus beaucoup plus difficiles à cadrer juridiquement et fonctionnellement (CNIL, directives européennes, lois internet...).

Ainsi devant des cahiers des charges aux périmètres étendus, il devient délicat d’anticiper le déroulé d'un projet plusieurs mois à l'avance. Il s'agit parfois d'un exercice à la limite de la prédiction. En effet, le développement informatique, aussi structuré et précis soit-il, est fait d'aléas qui prennent leurs sources dans un nombre important de variables indéterminées ou méconnues en début de projet.

les aléas sont les composantes d'un projet

Quelle est la réactivité du client ? Connait-on l'ensemble des règles métiers ? Les workflows sont-ils tous complets ? Les utilisateurs ont ils étés consultées dans la conception ? Tous les intervenants seront-ils prêts au bon moment ? Le chef de projet client est il décisionnaire ?

Autant de facteurs qui peuvent entraîner des difficultés à boucler un projet dans les délais. Cette problématique s'applique dans notre cas, sur des projets sur-mesure et non des projets sur étagère comme des produits à vendre.

@ Pour illustrer, on peut imaginer un constructeur de voitures, qui pour connaître parfaitement le coût de production d'un modèle doit maîtriser toute sa chaîne de montage de A à Z. Pour cela, il lui faut faire des essais, des prototypes, calibrer certaines pièces, optimiser son cycle de montage pour avoir un modèle de production avec un faible niveau de variations. Nous rencontrons exactement les mêmes contraintes pour nos projets et devons respecter ces différentes étapes de calibrage pour pouvoir déterminer le coût complet d'un projet.

Mais comment faire rentrer ces éléments d’étude dans un forfait ? Comment anticiper les modifications et prévoir le coût de ces aléas dans un mode de contrat qui verrouille le périmètre fonctionnel, les coûts et le planning ? Peut-on faire de l'innovation et être agile dans ce contexte ?

Le mode forfait vite dépassé

Le forfait est un concept de contractualisation facile à appréhender. C'est un contrat entre un prestataire et un client qui définit une prestation pour un budget et un délai. Il repose en grande partie sur le sacro-saint cahier des charges. Le client est donc rassuré et semble tout contrôler.

Pour des projets simples et courts, le mode forfait fonctionne et permet de donner un cadre de travail clair. Les équipes de développements appliquent à la lettre les éléments du cahier des charges. Il est aussi possible de prévoir des légères modifications au cours de la vie du projet, tant qu'elles restent à la marge. Malheureusement, très souvent la situation se complique, les petites modifications deviennent légion au fur et à mesure que le client prend en main son projet.

Au bout de quelques mois, le cahier des charges qui semblait si rassurant devient donc un vrai sujet friction tant il est difficile de s'en affranchir par le périmètre qui a été déterminé au départ. Les conversations client/prestataire se focalisent sur les détails du document, les interprétations possibles jusqu'à en oublier l'essentiel : le projet.

^ Le forfait est idéal si le client et le prestataire ont une connaissance qui couvre 100% du fonctionnel. C'est souvent le cas pour des projets "vitrines", c'est en revanche plus rare pour les projets sur-mesures. En effet, plus il est gros et complexe, plus le forfait devient incohérent et faussé. Pour palier cette distorsion entre l'estimation et la réalité, beaucoup de prestataire ont le réflexe de “sécuriser” le projet en rajoutant une marge fluctuante dans leur chiffrage.

Finalement, notre expérience nous démontre que le forfait peut être générateur, pour les deux parties, de frustration et de mécontentement. Personne n'est vraiment responsable car c'est le mode de contractualisation qui est à mettre en cause.

La régie comme norme ?

Posons d'abord les principes de la régie.

@ Il s'agit d'un fonctionnement qui lie le prestataire et le client sur une obligation de moyen et non de résultat. On prend comme acquis que le projet devra évoluer au cours de son développement et on privilégie le besoin client et la qualité. La régie s'affranchit des contraintes du cahier des charges pour se concentrer sur la valeur ajoutée perçue par le client.

Dans ce modèle, les méthodes agiles peuvent être utilisées. On prend le temps de construire un environnement de développement complet et une architecture technique fiable. La conception est orientée sur le long terme et permet donc la mise en place de tout l'outillage nécessaire à un travail de qualité (bonnes pratiques, tests, review ou documentation).

Le point d'ancrage du cœur de la régie est la satisfaction, pour ce faire on privilégie l'écoute, le conseil et l'efficacité. Le prestataire organise également des points hebdomadaires (ou quotidiens) avec son client et établit régulièrement des sessions de planning poker pour estimer les développements.

@ Dans cette phase, le client pilote avec les équipes, les livrables et les priorités. Il est au cœur de la conception et des décisions.

En tant que prestataire, cela nous offre plus d'espace pour jouer pleinement notre rôle de conseil sans rentrer dans des logiques comptables qui peuvent contraindre les choix techniques. Les discussions ne portent donc plus sur le périmètre mais sur ce que l'on peut améliorer du projet.

Vous l'aurez compris, ce modèle allie transparence et confiance. Toutefois, cette façon de penser la gestion de projet n'est pas facile à mettre en place surtout si le client ne connait pas bien son prestataire.

Le prototype, période d'essai à emporter ?

Chez Wanadev, nous souhaitons remettre la réussite du projet au cœur de la relation avec nos clients. Notre discours se veut clair, certains projets ne peuvent réussir au forfait. Nous proposons donc de combiner la réalisation d'un prototype avec la régie.

La phase de prototypage est essentielle car au-delà des validations technique, elle permet à chacun des protagonistes de roder sa façon de communiquer dans le projet, d'évaluer sa vélocité et enfin, côté client, de valider son concept de base à moindre coût.

Cette première phase rassure les parties et, pour le client, elle est un bon moyen d'évaluer le niveau de satisfaction apporté par le prestataire. Une sorte de période d'essai. Cette étape porte un nom, le POC (Proof of concept).

Après cette première phase, nous engageons alors un contrat de régie renouvelable mensuellement. L’un des deux n'est pas satisfait ? Chacun peut arrêter d'un mois à un autre. C'est simple, transparent et le code source est transmis au client dès l'arrêt de la prestation.

Cette étape est déterminante, elle est un facteur important pour rassurer et sécuriser chacun sur la suite qui pourrait être donnée au projet.

Vers une collaboration sur le long terme

Loin d'être anecdotique, le développement d'un environnement technique de qualité est très important pour la réussite d'un projet. Cette valeur ajoutée n'est pas toujours facile à identifier au premier abord car elle est parfois masquée par certains artifices. De ce fait, un projet fait dans la souffrance ou dans la précipitation sera fragile et difficile à maintenir dans le temps. Relation directe avec la notion de dette technique.

À vous donc de choisir entre les différents modes de contrats.

Pour cela, posez-vous des questions sur la pérennité, le degré de difficulté et la valeur de la part technique de votre projet. Sachez enfin qu'un projet technique réussi est un projet qui va évoluer dans le temps pour s'adapter aux nouvelles utilisations, aux nouveaux supports mais aussi s'améliorer fonctionnellement.

Une conception sérieuse est donc essentielle.

Enfin, si vous souhaitez creuser le sujet, je vous recommande cette conférence autour des contrats agiles.

Nous serions ravis de discuter avec vous de votre projet ou de répondre à vos questions sur les modes de contrats. N'hésitez pas à prendre contact avec nos équipes, en plus il paraît que notre café est excellent !