Un partenariat, pas un projet
Un projet a un scope fixe et une fin. Le problème : ce qui compte en mois 1 ne sera pas ce qui compte en mois 6. L'IA évolue chaque trimestre. Un scope figé en mars est obsolète en août.
Le modèle : un partenariat par sprints. L'unité de livraison est le sprint — un bloc de travail scopé avec un livrable concret et une gate de décision. Le client achète des sprints. Il peut en acheter un seul, ou s'engager sur un volume.
Livraison continue
Chaque sprint produit un résultat opérationnel. Pas de mois sans livrable visible.
Pas de lock-in
Arrêtez après n'importe quel sprint. La gate review est le point de décision naturel.
Repriorisation à chaque gate
Ce qu'on construit ensuite est décidé ensemble, pas présupposé. Le backlog s'adapte.
3 semaines. Un livrable. Une décision.
Le sprint est l'unité fondamentale. Durée fixe (3 semaines), scope variable (s'adapte au timebox). Si le travail ne rentre pas, on coupe le scope — jamais la deadline.
Build
L'équipe construit les livrables scopés.
Build + Test
Livrable fonctionnel. Mid-sprint check avec le sponsor. Tests sur cas réels.
Itération + Gate
Feedback intégré. Tests sur mandats réels. Gate review : Go / Iterate / Stop.
Dimensionnement
Chaque cas d'usage a une classe de complexité, basée sur ce qu'il touche — pas sur des heures estimées.
| Taille | Ce que ça signifie | Profil technique |
|---|---|---|
| S — Quick Win | Un workflow, input/output clair, données existantes | Prompt/config, ou code léger |
| M — Standard | Plusieurs étapes ou 1 intégration, discovery nécessaire | Code custom + 1 intégration, ou logique IA complexe |
| L — Complex | Cross-système, multiples stakeholders, UI custom | Intégrations multiples + dashboard + data pipeline |
| XL — Multi-sprint | Changement d'architecture, dépendances cross-workflow | Découpé en tranches M ou L livrables par sprint |
Capacité par sprint : 1 L, ou 1 M + 1-2 S, ou 2 M. Le sprint card rend cette composition visible avant le démarrage.
Sprint Card
Avant chaque sprint, le sponsor reçoit un sprint card :
Gate Review
30 minutes avec le sponsor. Démo live sur données réelles. Trois décisions possibles :
Go
Le livrable atteint les critères. Passer au prochain item du backlog.
Iterate
L'approche est bonne mais le livrable a besoin de raffinement. Même zone, focus plus serré.
Stop
La priorité a changé ou l'approche ne fonctionne pas. Reprioriser. C'est un apprentissage.
Définition de "Done" en IA
L'IA est probabiliste. La definition of done traditionnelle est insuffisante.
| Dimension | Ce que ça signifie |
|---|---|
| Données réelles | Testé sur du travail réel, pas sur des données de démo. |
| Test humain | Un utilisateur réel (pas le constructeur) l'a utilisé de manière indépendante. |
| Modes d'échec | Documentés : "Bon pour X, peu fiable pour Y, ne pas utiliser pour Z." |
| Gouvernance | Quelles données entrent. Ce qui nécessite une revue humaine. |
| Prochaine étape | Ce que le prochain sprint fait avec ce livrable. |
Le point d'entrée
Sprint 0 est différent. C'est la fondation stratégique sur laquelle tout le reste se construit. 1 semaine. Dirigé par l'AI Partner en direct — pas de délégation.
Processus
L'AI Partner construit une compréhension profonde du fonctionnement actuel — chaque workflow, chaque point de douleur, chaque opportunité.
La méthode de collecte est flexible : workshop collectif, entretiens individuels, revue documentaire, ou combinaison. Le client choisit comment fournir l'input. L'AI Partner structure et enrichit.
Par workflow : ce qui le déclenche, qui fait quoi, où va le temps, où est la douleur, où l'IA peut intervenir, impact et faisabilité, contraintes de gouvernance.
L'AI Partner enrichit chaque item du backlog avec son jugement technique : faisabilité, dépendances, sprint fit, critères de succès.
Spikes techniques sur les items prioritaires : est-ce que ça marche ? Quelle approche ?
Présentation au sponsor : backlog priorisé, proposition Sprint 1.
Confirmation du scope Sprint 1. La fondation stratégique est posée. Le premier sprint démarre.
Livrables Sprint 0
Cartographie workflows
État actuel de chaque workflow — visuel.
Backlog priorisé
Ordonné par impact × faisabilité, enrichi techniquement.
Blueprint cible
Humain vs IA à chaque étape du workflow #1.
Cadre de gouvernance
Classification données, politique outils, règles de revue.
Recommandation stack
Architecture + rationale de décision.
Scope Sprint 1
Confirmé par le sponsor, prêt à exécuter.
La liste vivante
Le backlog est la liste priorisée de toutes les opportunités de transformation IA. Né en Sprint 0, maintenu par l'AI Partner, visible par le client, revu à chaque gate et copil.
Template d'un item
Deux modes : En Sprint 0, capture légère (nom, workflow, douleur, scores bruts) — vitesse et quantité. Après Sprint 0, template complet — enrichi par l'AI Partner avec le détail technique.
Ownership : Le backlog est partagé mais maintenu par l'AI Partner. Le client peut le voir, le référencer, remonter des items. L'AI Partner met à jour la faisabilité, ajoute les items découverts en sprint, résout les dépendances.
Deux rythmes
| Moment | Qui | Fréquence | Durée | But |
|---|---|---|---|---|
| Sprint gate | AI Partner + sponsor | Toutes les 3 semaines | 30 min | Démo. Go/Iterate/Stop. Scope sprint suivant. |
| Copil stratégique | AI Partner + leadership | Sur déclencheur | 45-60 min | Revue backlog, repriorisation, alignement. |
Sprint gate = décisions d'exécution. Un sponsor, décisions rapides, opérationnel.
Copil = décisions stratégiques. Leadership complet, vue large, stratégique. Le copil n'est pas sur un calendrier fixe — il est déclenché quand c'est nécessaire :
Après 2-3 sprints — checkpoint naturel pour revoir les progrès et reprioriser.
Quand une gate décide "Stop" — une redirection stratégique nécessite l'input du leadership.
Quand un nouveau domaine workflow commence — le leadership valide la direction avant de construire.
Quand les priorités externes changent — marché, clients, événements organisationnels.
Codebase propriétaire. Pas de SaaS.
L'AI OS est un code source détenu par le client. Pas une configuration SaaS. Pas une dépendance plateforme. Un actif au bilan.
Pourquoi du code, pas de la configuration
IP
L'OS est la propriété intellectuelle du client. Le code peut être protégé, licencié, étendu.
Version control
Chaque changement tracé dans git. Chaque décision auditable. Chaque déploiement reproductible.
Indépendance
Aucune dépendance à la roadmap d'un fournisseur. Le code fonctionne toujours.
Tarification
- Cadrage stratégique complet
- Cartographie workflows
- Backlog priorisé
- Premier outil livré
- Blueprint + stack rec.
- 1 L ou 1 M + 1-2 S
- Livrable opérationnel
- Test sur données réelles
- Gate review + décision
- Enablement inclus
- Capacité doublée
- 2 M + 2-3 S
- ou 1 L + 1 M + 1-2 S
- Même gate review
- Pour jalons critiques
Engagement volume
L'engagement est sur un nombre de sprints, pas sur une durée. Les sprints peuvent être espacés selon vos besoins.
Continuité
Le codebase est toujours en état de déploiement et documenté. Chaque sprint respecte : "un autre développeur pourrait reprendre ce travail." Si le partenariat pause ou s'arrête, le client a un système fonctionnel qu'il détient entièrement.
Infrastructure
Les coûts d'infrastructure (hébergement, APIs IA) sont à la charge du client — pas inclus dans le prix des sprints. L'AI Partner sélectionne et configure ; le client possède et paie.
Change management intégré, pas boulonné
La transformation IA échoue plus souvent pour des raisons organisationnelles que techniques. La méthode adresse ça dans la structure des sprints — pas dans un programme de change séparé.
Le premier sprint livre un outil qu'un leader senior utilise sur du travail réel. L'usage visible de l'IA par le leadership en fait un signal de statut, pas un signe de faiblesse.
Chaque gate review est une démo live. Les gens voient l'outil fonctionner sur des données réelles. La preuve sociale se construit naturellement dans l'organisation.
Formation, documentation et collecte de feedback font partie du sprint — pas d'un workstream "change management" séparé.
Le leadership review : qui utilise quoi, où l'adoption stagne, quelles barrières lever.
Barrières que cette méthode évite
| Échec courant | Comment les sprints le préviennent |
|---|---|
| Tentatives IA échouées | Outil fonctionnel en Sprint 1. Preuve par l'action, pas par des documents stratégiques. |
| Fatigue d'adoption | L'IA s'intègre aux outils existants (Google Workspace, etc.). Pas de nouvelle plateforme. |
| Résistance culturelle | Le leadership modélise le comportement en premier. L'IA devient un signal de compétence. |
| Paralysie stratégique | Construire EST la stratégie. Preuve par l'action. |
| Overwhelm big-bang | Un sprint à la fois. Chaque sprint est gérable. Chaque gate est un point de décision. |