1 2 3 4 5 6 7 8

La régie forfaitée

Ce type de contrat combine la souplesse de la location d’équipe en régie avec la sécurité du développement au forfait, en garantissant un résultat, fonctionnel et financier.

Elaboration de l'offre

La régie forfaitée
A partir d'un cahier des charges qui n'a pas besoin d'être exhaustif, nous élaborons un cadre, aussi détaillé que possible, qui fixe les limites du projet. Nous vous fournissons une évaluation détaillée des charges et du prix sous forme d'une fourchette :
Charge Cible : C'est la charge cible par rapport à notre compréhension du projet. Elle sert de base au suivi de projet BelerStep.
Charge Maxi : Le prix associé à cette charge est la borne haute qui limite le coût du projet. En cas de dépassement du budget temps, le projet sera finalisé sans facturation supplémentaire. Bien entendu, dans le cadre défini dans le contrat.

Nous pouvons élaborer un contrat de régie forfaitée réaliste beaucoup plus rapidement qu'un contrat au forfait.

Suivi du projet

par le Client
Le suivi est identique à celui de la régie classique :
Compte-rendu d'activité quotidien.
Bilan hebdomadaire et évolution prévisionnelle : le Step.
Les précisions fonctionnelles et les évolutions minimes sont intégrées immédiatement dans le Step d'origine.

Les demandes d'évolution et les modifications hors cadre sont également intégrées comme suppléments et évaluées dans la semaine. Tant que ces demandes n'impactent pas la charge Maxi, elles sont prises en compte naturellement dans le projet.

La capacité d'évolution des spécifications et la réactivité sont donc préservées.
Gestion de projet
Agile avec BelerStep
BelerStep est notre logiciel interne de suivi de projet, développé et enrichi en permanence depuis plus de dix ans. Il s'agit d'une implémentation simplifiée de Scrum qui permet de suivre quotidiennement l'avancement d'un projet et la prévision de charge pour chaque tâche.


BelerStep a été conçu pour mettre en pratique au quotidien les quatre principes des méthodes Agile :
Privilégier les individus et les interactions plutôt que les process et les outils.
Fournir du logiciel qui marche plutôt que de la documentation exhaustive.
Se focaliser sur la collaboration avec le client plutôt que sur les aspects contractuels.
S'adapter rapidement aux changements plutôt que de suivre un planning rigide.

Inspiré de Scrum, BelerStep vise à accélérer le développement de projets en fournissant des indicateurs de performance simples et rapides à évaluer.

Quelques principes de Scrum :
Des cycles de développement de 2 à 6 semaines, les Sprints, conclus par une livraison opérationnelle.
Une gestion fine des priorités en liaison avec le client.
Une réunion formelle brève et quotidienne au sein de l'équipe de développement, pour que les progressions et difficultés soient diffusées et impactées.
Une prise en charge rapide des demandes de modification et une intégration permanente des développements.

La régie forfaitée est un cadre contractuel bien adapté à à une méthode Agile, car elle préserve la réactivité tout en obligeant à un reporting précis et quotidien.

Pourquoi adopter

la régie forfaitée ?
En mode forfait traditionnel, une équipe de programmeurs aura toujours tendance à se focaliser sur l'objectif technique du contrat tel que figé au début du projet. Ce qui conduit à éviter les changements de spécification ou d'environnement (méthode d'analyse, outils, ...) pour ne pas perturber les évaluations d'origine. Les nouvelles demandes du client doivent passer par des avenants.



Avec un chef de projet expérimenté et pragmatique ce comportement, bien humain, se traduira par une réalisation à minima des fonctionnalités contractuelles. Avec un chef de projet enthousiaste et perfectionniste le résultat est dans 70% des cas un dépassement de budget plus ou moins colossal, une explosion du planning et un raidissement de la relation avec le client. Dans les deux cas le développement offshore au forfait conduit à une frustration soit côté client, soit côté fournisseur, soit des deux côtés.

Au contraire, en mode régie forfaitée, notre équipe et notre client vont avoir tendance à travailler ensemble pour faire entrer dans le budget le maximum de satisfaction au besoin de base (la « vision » du projet). La recherche d'efficacité se manifeste par des adaptations réalistes de la spécification, et des choix pragmatiques d'organisation.



Scrum facilite la conduite de projet car il permet de visualiser sur des cycles courts :
la progression du produit effectivement développé par rapport au besoin ;
l'évolution du coût par rapport au budget ;

Quelques mises au point

Fait-on l'impasse sur la documentation ?
Surtout pas! Scrum induit explicitement une documentation fonctionnelle périodique, les backlogs du projet. Et notre contrat de régie forfaitée inclut les temps de rédaction : l'élaboration d'une documentation de maintenance, à la fin de certains cycles, est indispensable pour la transmission du logiciel aux informaticiens du client.

La régie forfaitée et le développement Agile s'adaptent–t-ils à la création de progiciels peu définis au départ, sans spécification fonctionnelle écrite ?
Malheureusement non! Nous sommes parfois confrontés à ce genre de demande : Le client a une vision floue du produit à créer, essentiellement basée sur des concepts généraux repris de logiciels concurrents. Un autre cas assez fréquent ces derniers temps est la demande de «copier» un puissant site d'e-commerce, ou une application mobile à succès. Aucune méthode ne peut pallier au manque d'implication ou de compétence fonctionnelle du client. Nous proposons dans ce cas une étude fonctionnelle préalable en régie.

Le développement 3-tiers est-il compatible avec un mode de travail Agile ?
Chez Beler, nous avons une bonne expérience du développement 3-tiers, en .Net, en PHP / ZEND Framework, et en Objective C sur des projets de quelques mois à plusieurs dizaines d'années.hommes. Certains projets incluaient la construction de grosses bibliothèques de classes IHM et de manipulations de données ... On nous a demandé parfois une certaine approche du développement 3 tiers, qui implique une architecture lourde et la conception de bibliothèques, ou même d'un SDK spécifique, avant d'obtenir un résultat visible pour les utilisateurs.

A notre avis, cette approche est totalement incompatible avec un développement Agile. Il s'agit d'une autre approche stratégique du développement de progiciel, qui peut amener de bons résultats à long terme, mais qui n'a rien d'Agile. Nous conseillons plutôt d'aborder la phase de codage en partant d'une conception d'architecture simplifiée, ou plus exactement « incomplète », et d'adopter des bibliothèques du commerce, quitte à les enrichir quand elles sont fournies avec les sources. De toute façon, la plupart des SDK actuels, et en particulier .NET, induisent naturellement, sans gros efforts, un développement 3-tiers. Dans la plupart des cas, les highlights ergonomiques, qui vont différencier un site ou un progiciel de ses concurrents peuvent être implémentés en utilisant des composants du marché à condition de bien les sélectionner

Notre préconisation est de se concentrer sur les classes métiers et sur la vision « orientée utilisateurs » du produit plutôt que sur la création d'un pseudo SDK ou d'une énième bibliothèque de composants.

De nombreuses sociétés de service vendent l'idée contraire, en prétendant que le coût de cette lourde phase préparatoire sera rentabilisé grâce aux bibliothèques d'objets spécifiquement orientées vers les fonctionnalités client. C'est carrément une arnaque.