i

Description

Un embranchement de routes vu du ciel, où il faut choisir sa direction

Source

Wikideas1 · page d’origine

Licence

CC0 Domaine public

Photo d’origine, non retouchée. L’arrière-plan en est une version stylisée par le site.

Choisir sa méthode et hybrider

Vous saurez choisir une méthode par le contexte (taille, incertitude, réglementation, contrat, maturité, nature data) plutôt que par la mode, avec un arbre de décision et une table de…

En bref

• Vous saurez choisir une méthode par le contexte (taille, incertitude, réglementation, contrat, maturité, nature data) plutôt que par la mode, avec un arbre de décision et une table de bascules.
• Vous connaîtrez les hybridations réalistes : « wagile », Scrum + Kanban pour le run, cadrage prédictif + exécution agile, gouvernance par étapes + sprints, kits versionnés + flux continu.
• Vous saurez contractualiser une démarche itérative (forfait à périmètre variable, deux phases, tranches conditionnelles).
• Vous saurez conduire le changement de méthode : démarrer petit, mesurer, éviter le « big bang ».
• Vous repérerez les pièges classiques et les façons de les désamorcer.

Sur cette page

1. 1. Un arbre de décision par contexte
2. 2. Les six dimensions, une par une
   1. 2.1 Taille
   2. 2.2 Incertitude
   3. 2.3 Réglementation et exigence de preuve
   4. 2.4 Contrat
   5. 2.5 Maturité
   6. 2.6 Nature data
3. 3. Cas typiques et méthodes recommandées
4. 4. Hybridations réalistes
   1. 4.1 « Wagile » (water-scrum-fall) : le plus répandu, le plus critiqué
   2. 4.2 Cadrage prédictif + exécution agile
   3. 4.3 Scrum + Kanban pour le run (Scrumban d'équipe)
   4. 4.4 Gouvernance par étapes + sprints (PRINCE2/PMI + Scrum)
   5. 4.5 Prédictif pour la structure, agile pour le détail
   6. 4.6 Kits versionnés + flux continu en amont
   7. 4.7 Hybridations à éviter
5. 5. Contractualiser
6. 6. Conduire le changement de méthode
7. 7. Pièges
8. 8. Contribution de l'IA
9. 9. Voir aussi

Niveau : 🟢→🔴

1. Un arbre de décision par contexte#

🟢 Novice — Choisir une méthode revient à répondre à quelques questions dans l'ordre, en commençant par ce qui élimine le plus de possibilités. L'ordre proposé : les contraintes externes (réglementation, contrat), puis la nature de l'incertitude, puis l'organisation (taille, maturité).

Ce schéma est un point de départ, pas un algorithme. Il est volontairement incomplet : il oublie le facteur humain et l'historique de l'équipe (voir §2 et §7).

2. Les six dimensions, une par une#

🟡 Pratique — Pour chaque dimension : la question, ce qui oriente vers le prédictif ou l'adaptatif, et le piège.

2.1 Taille#

2.2 Incertitude#

Distinguez trois sortes d'incertitude : sur le besoin (que veut-on ?), sur la solution (comment le faire ?), sur les données (que contiennent-elles ?). Plus le besoin est flou, plus il faut de boucles courtes de feedback ; plus la solution est incertaine, plus il faut de prototypes et de spikes ; plus les données sont incertaines, plus il faut de profilage tôt. Les projets data cumulent souvent les trois.

2.3 Réglementation et exigence de preuve#

Quand un auditeur, un régulateur ou un client demande qui a décidé quoi, quand, sur quelle preuve, il faut de la traçabilité. Ce n'est pas incompatible avec l'agile : une équipe agile peut produire un dossier de preuves (user stories avec critères d'acceptation, résultats de tests archivés, journal des décisions) pour autant que ce soit planifié comme du travail (Definition of Done étendue). Dans un cadre à preuve lourde (santé, ferroviaire, finance réglementée), la phase de conception et la vérification restent séquencées et formelles ; l'agile s'applique à l'intérieur de chaque phase.

2.4 Contrat#

Le contrat est souvent la vraie contrainte de méthode (voir §5). Un forfait ferme sur périmètre détaillé pousse au prédictif ; un contrat en régie ou à enveloppe, à l'itératif. Un projet interne (sans contrat) laisse plus de liberté, mais le budget annuel joue le même rôle.

2.5 Maturité#

La maturité se lit sur trois axes : technique (tests automatisés, intégration continue, déploiement reproductible), produit (un interlocuteur métier capable de décider et priorisé), organisation (le management accepte-t-il l'autonomie ?). Règle empirique : ne pas ajouter de cérémonies là où l'ingénierie est faible ; on commence par outiller le test et la livraison (voir CI/CD). La matrice intégration et livraison continues donne les niveaux.

2.6 Nature data#

Ce qui change quand c'est de la donnée (détail dans méthodes spécifiques à la data) :

• l'incrément est une donnée fiable (chargée, rapprochée, historisée), pas une fonction : on teste des chiffres ;
• l'historisation et le rejeu (idempotence) sont des décisions structurantes et difficiles à renverser ;
• les migrations (version de base, de modèle, de produit) sont des projets prévisibles à plan et recette comparatifs ;
• la volumétrie et la confidentialité limitent les environnements de test ;
• le métier recetteur est le goulot (disponibilité, légitimité) ;
• les rapports consommés par des tiers (clients liés par un identifiant de mesure, par exemple) figent des contrats d'interface : on ne renomme pas librement une mesure ou une colonne.

3. Cas typiques et méthodes recommandées#

🟡 Pratique — Cas, avec contexte et recommandation par défaut (à adapter).

4. Hybridations réalistes#

🟡 Pratique — La pureté n'est pas un objectif : presque toutes les organisations performantes combinent. L'art est de le faire explicitement, sans casser les propriétés qui font marcher chaque brique.

4.1 « Wagile » (water-scrum-fall) : le plus répandu, le plus critiqué#

Un amont prédictif (cahier des charges, budget, planning contractuel), une exécution en sprints, un aval prédictif (recette formelle, mise en production par lot). Le terme a un ton ironique (water-Scrum-fall) parce que le feedback ne traverse pas l'amont et l'aval : les sprints optimisent ce qui est déjà figé.

4.2 Cadrage prédictif + exécution agile#

Le plus utile pour les projets avec contrat ou budget annuel : une phase de cadrage courte (2 à 6 semaines) produit une vision, un périmètre en enveloppes (MoSCoW), un budget et un horizon, une architecture cible et un profilage de sources ; puis l'exécution est itérative dans cette enveloppe. Le périmètre varie, le cadre non.

C'est l'esprit de PRINCE2 + agile ou de DSDM : la gouvernance prend la forme d'étapes avec tolérances ; au sein d'une étape, la livraison est itérative. Voir prédictives et DSDM.

4.3 Scrum + Kanban pour le run (Scrumban d'équipe)#

Une équipe BI qui fait du projet et du support :

4.4 Gouvernance par étapes + sprints (PRINCE2/PMI + Scrum)#

La gouvernance (business case, tolérances, comité) enveloppe les sprints. Le chef de projet traduit les revues de sprint en rapports de progression pour le comité (burn-up, objectifs atteints) ; le Product Owner garde la priorisation détaillée. Règle : un seul tableau de bord, alimenté par les artefacts agiles, pas un second jeu de rapports.

4.5 Prédictif pour la structure, agile pour le détail#

Pour un projet de grande taille et à dépendances : un plan directeur (jalons macro, architecture, interfaces gelées en premier : contrats de données) et des équipes agiles qui l'exécutent par domaine. Les interfaces sont le point où le prédictif est justifié (elles coûtent cher à changer) ; l'intérieur des modules reste souple.

4.6 Kits versionnés + flux continu en amont#

Quand la livraison est contrainte à des kits d'installation (clients à qui l'on livre par versions numérotées, fenêtres d'installation chez eux) : l'amont (développement) peut être continu (Kanban, intégration continue sur une branche principale), tandis que l'aval est rythmé par les versions (gel, stabilisation, recette de version, ligne de maintenance). C'est un train de livraison à la cadence de la version, avec un flux à l'intérieur. Il faut alors résoudre les branches (voir stratégies de branches) et la maintenance parallèle de plusieurs versions.

4.7 Hybridations à éviter#

5. Contractualiser#

🟡 Pratique — Le contrat est un mécanisme de répartition du risque : qui supporte le risque de dépassement ? Dans le forfait ferme sur périmètre, c'est le prestataire ; en régie, le client. Le défi d'une démarche itérative est de répartir le risque d'incertitude de façon acceptable pour les deux.

Éléments de clauses qui rendent un contrat compatible avec l'itératif :

• un objectif et un budget fixes, un périmètre évolutif encadré par une procédure de changement légère (un échange équivalent : on ajoute un élément, on en retire un d'égale valeur) ;
• une recette continue (revue de sprint) avec critères d'acceptation objectivables (chiffres, tolérances) ;
• un droit de sortie à chaque jalon (le client peut arrêter en payant ce qui est livré) ;
• un accès garanti au métier (disponibilité du Product Owner : c'est une obligation du client, à écrire) ;
• la propriété et la documentation des livrables (code, modèle, scripts, jeux de test) ;
• la réversibilité (transfert de connaissance, accès aux dépôts).

6. Conduire le changement de méthode#

🟡 Pratique — Changer de méthode est un projet de conduite du changement, avec ses résistances. Les approches qui échouent le plus : le big bang (tout changer un lundi), la formation seule (sans pratique encadrée), la méthode imposée d'en haut (sans compréhension du « pourquoi »).

Un parcours réaliste en cinq étapes :

1. Diagnostiquer : mesurer l'état actuel (lead time, fréquence de livraison, taux de défauts, satisfaction). Sans point de départ, aucune amélioration n'est démontrable.
2. Choisir un périmètre pilote : une équipe volontaire, un produit bien délimité, un sponsor. Éviter le projet le plus critique et le plus insignifiant.
3. Démarrer par les pratiques à plus fort levier et moindre coût : visualiser le travail, limiter le WIP, raccourcir la boucle de recette, tests automatisés sur le critique ; ensuite les cérémonies.
4. Mesurer et ajuster à intervalles courts (rétrospective, revue à 6–8 semaines) ; décider d'élargir, d'ajuster ou d'arrêter.
5. Essaimer par la preuve : les résultats du pilote convainquent plus que les slides ; communautés de pratiques pour diffuser.

Les leviers à activer : sponsor visible ; formation par la pratique (coaching à côté de l'équipe) ; adaptation des outils (tableaux, flux de travail dans l'outil de suivi) ; alignement des indicateurs (ne pas continuer à mesurer la conformité au plan si l'on veut de la valeur) ; traitement des peurs (le rôle de chacun change).

🔴 Expert — La résistance a des causes légitimes. Un chef de projet voit son rôle de contrôle diminuer, un responsable voit sa visibilité menacée, un développeur craint l'exposition de la production quotidienne. Les ignorer, c'est perdre. Les écouter, c'est souvent découvrir un vrai besoin de gouvernance que la nouvelle méthode doit servir autrement (rapports issus des artefacts, revues de portefeuille). La matrice équipe et collaboration et le thème adoption et conduite du changement donnent des repères.

7. Pièges#

🟡 Pratique — Les erreurs classiques de choix et d'hybridation, avec symptôme, cause et remède. Le catalogue général est dans pièges et bonnes pratiques.

🧪 Exemple de décision tracée — Fiche de contexte d'un lot : Lot « nouvelle famille de mesures de linéaire » — équipe de 5, métier disponible 2 h/semaine, besoin évolutif, source stabilisée, pas de contrat externe, livraison en kits trimestriels, maturité technique moyenne (tests de données partiels). Choix : Scrum 2 semaines, revue chiffrée avec le métier à chaque sprint, Definition of Done incluant rapprochement et note de version ; revue de méthode dans 8 semaines ; critère d'alerte : plus de 20 % du sprint consommé par le support → passage à Scrumban.

8. Contribution de l'IA#

🤖 IA — Peut préparer et outiller la décision ; ne la prend pas.

Exemple de prompt : « À partir de ces 12 rétrospectives, regroupe les irritants récurrents par thème (recette, dépendances, outils, charge), compte leur fréquence et propose trois expérimentations de six semaines avec indicateur de réussite. »

Limites : l'IA n'a pas de mémoire de votre contexte, ignore la politique interne, et propose volontiers des réponses « équilibrées » qui évitent le choix difficile. Voir IA et conduite de projet.

9. Voir aussi#

• Les méthodes : prédictives · agiles et lean · spécifiques à la data · comparatif.
• Scrum : le cadre · en pratique · et data · fondamentaux.
• Livraison : CI/CD · CI/CD pour la data · pièges et bonnes pratiques.
• Outils : stratégies de branches · Azure DevOps / TFS · comparatif des outils.
• Maturité : gouvernance et pilotage · cadrage et vision · budget, valeur et bénéfices · délais et industrialisation DataOps.
• Glossaire · Notation.

✻ Rédigé par Claude Sonnet 5.5