Retour aux articles

L'agence

WanadevStudio

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 !

Commentaires

Merci pour votre article très clair ! Concernant le prototype que vous proposez au client, le facturez-vous à coût moindre ? Un contrat spécifique est-il rédigé et signé pour celui-ci ?
  • Tests automatiques fonctionnels d’applications 2D/3D

    Il y a 7 mois

    Comme nous le disions dans cet article, l’automatisation des tests dans le développement logiciel est indispensable : dès lors qu’une application commence à avoir un minimum d’importance, les tests automatiques permettront de gagner énormément de temps en évitant de reproduire ad vitam æternam les mêmes tests manuels, et éviteront beaucoup de régressions. Dans cet article, nous allons présenter différents types de tests automatiques dans le cadre plus spécifique d’applications 2D/3D, puisque c’est ce que nous faisons ! Cela va du test basique qui clique sur 3 boutons aux tests de plusieurs minutes reproduisant les actions comme un véritable utilisateur. Accrochez-vous, c’est parti !

  • Configurateur web à l'abonnement : forces et faiblesses

    Il y a 8 mois

    Aujourd’hui, si vous cherchez à mettre en place un configurateur sur votre site, deux grandes possibilités s'offrent à vous : les solutions par abonnement (du type SaaS) ou le développement sur mesure. Au premier abord, les solutions semblent proches, mais les enjeux sur le long terme eux, sont bien différents.

  • Les frameworks front, tous les mêmes !
    Méthodologie

    Il y a 9 mois

    C'est une phrase que j'ai osé sortir un jour dans la salle de pause de Wanadev. Je ne sais plus exactement avec quel collègue je discutais, j’essayais de le rassurer, il possédait déjà une certaine expérience avec React et allait devoir, en arrivant sur le projet sur lequel je travaille, se mettre à Vue.
    Il a malheureusement fallu qu'un autre collègue de passage nous entende pour ne pas trouver la conversation inintéressante et suggérer que j'en fasse un petit talk pour nos réu du lundi. Et, de fil en aiguille, me voilà en train d'en faire un article de blog. Comme quoi, note pour moi-même, il faut toujours se méfier des discussions dans les salles de pause.

  • [NOVEMBRE 2021] C'est la gazette de Wanadev !
    Méthodologie

    Il y a 12 mois

    Retrouvez ici les informations et actus du mois de novembre de l'Agence! Au programme de cette édition : découvrez le configurateur de fenêtre développé pour Caseo, recontrez François Deleglise, notre directeur communication et un nouvel espace de jeu pour les professionnels du loisir en VR. Bonne lecture !

  • Un peu d'ingérence dans votre infogérance ?
    Méthodologie

    Il y a 2 ans

    Même si les impacts sont difficiles à mesurer, on peut dire qu’il a eu un avant et un après incident OVH. Sans épiloguer sur l'incendie du 5 mars 2021 dernier, un petit vent de panique a soufflé sur les milliers de clients découvrant les problématiques de sécurisation des données. Les réactions à chaud d'une partie des utilisateurs (touchés ou non) montrent la méconnaissance et l'incompréhension qui existent dans les offres d'hébergement. Qui est responsable ? Qui fait quoi ? Comment vérifier mon offre ? Voici quelques clés de compréhension.

  • Améliorer la qualité avec les tests et la review

    Il y a 2 ans

    L’importance des tests et de la revue de code dans le cadre du développement logiciel est parfois négligée ou passée au second plan. Cet article a pour but de montrer que les tests logiciels constituent une étape cruciale qu’il faut considérer avec beaucoup de rigueur.