Une charte de projet qui ne liste pas ce qui est exclu du périmètre laisse la porte ouverte à toutes les demandes futures. Et sans un décideur nommé pour trancher les désaccords, chaque arbitrage relance le débat depuis le début.
Ce qu’une charte de projet décide, et ce qu’elle ne décide pas
Une charte de projet n’est pas une présentation qui reformule l’objectif avec des mots plus vendeurs. Ce document a une fonction précise : il fixe, avant que le travail ne commence, les points sur lesquels personne ne pourra revenir sans passer par une décision explicite. C’est un contrat de cadrage, pas un support de motivation. Si votre charte ressemble à une plaquette commerciale, elle ne sert à rien le jour où un désaccord surgit.
Concrètement, une charte décide huit choses : l’objectif du projet formulé de façon vérifiable, le périmètre avec ses exclusions, le nom de la personne qui tranche en cas de désaccord, le rôle réel de chaque partie prenante, les livrables et leurs critères d’acceptation, les jalons qui marquent une étape réelle, le budget et les moyens engagés, et les risques ainsi que les hypothèses identifiés au départ. Ces huit points suffisent à cadrer un projet de TPE, quelle que soit sa taille.
Ce qu’elle ne décide pas, en revanche, c’est le détail du travail au quotidien. La charte ne dit pas comment l’équipe organise ses journées, ni quel outil elle utilise pour suivre ses tâches, ni dans quel ordre exact les développeurs codent les fonctionnalités. Ce niveau de détail relève de la gestion de projet au jour le jour, pas du cadrage initial. Confondre les deux est une des raisons pour lesquelles certaines chartes deviennent des documents de trente pages que personne ne relit jamais.
Le tableau suivant résume les sections d’une charte, ce qu’on y écrit concrètement, et la question à laquelle chaque section répond. Gardez-le sous les yeux pendant que vous rédigez la vôtre : si vous ne pouvez pas répondre à une des questions, la section correspondante n’est pas terminée.
| Section de la charte | Ce qu’on y écrit | Question à laquelle elle répond |
|---|---|---|
| Objectif | Le résultat attendu, formulé de façon mesurable et daté | À quoi ressemble la réussite du projet ? |
| Périmètre inclus et exclu | Ce qui sera livré et ce qui ne le sera explicitement pas | Où s’arrête le projet ? |
| Décideur unique | Le nom de la personne qui tranche en cas de désaccord | Qui a le dernier mot ? |
| Parties prenantes | Qui fait quoi, et qui décide quoi parmi elles | Qui est concerné, et pour quel rôle exact ? |
| Livrables et critères d’acceptation | Ce qui sera remis, et la façon de juger que c’est terminé | Comment sait-on que le travail est fait ? |
| Jalons | Les points de passage qui marquent une étape réellement franchie | Où en est le projet à un instant donné ? |
| Budget et moyens | Le montant engagé, le taux horaire, les heures estimées et le temps des personnes | Avec quoi le projet est-il financé ? |
| Risques | Ce qui pourrait mal se passer et la parade prévue pour chaque cas | Que fait-on si cela arrive vraiment ? |
| Hypothèses et dépendances | Ce dont dépend le projet sans que l’équipe ne le contrôle | Sur quoi le projet repose-t-il sans garantie ? |
| Validation | Qui a approuvé la charte, et à quelle date | Le projet a-t-il vraiment démarré, ou reste-t-il en discussion ? |
Le moment où on l’écrit, et pourquoi trop tôt ou trop tard la rend inutile
Le bon moment pour rédiger une charte se situe entre deux dates précises. Il faut avoir dépassé le premier échange avec le client, celui où il exprime une intention générale, mais ne pas avoir encore commencé à produire quoi que ce soit. Écrire la charte trop tôt, dès le premier appel, produit un document plein de suppositions non vérifiées. Vous devinez le budget, vous devinez le délai, vous devinez ce que le client considère comme prioritaire. Ce genre de charte se révèle fausse dès la deuxième semaine du projet.
À l’inverse, écrire la charte trop tard, une fois que l’équipe a déjà commencé à travailler, la rend inutile pour une raison simple : les décisions qu’elle est censée fixer ont déjà été prises informellement, par un e-mail, par un message rapide, ou par un choix pris sur le terrain sans en informer tout le monde. À ce stade, la charte ne fait que constater des faits déjà accomplis. Elle perd sa fonction de cadrage préalable et devient un compte-rendu déguisé.
Le signal fiable pour savoir que le moment est venu, c’est d’avoir obtenu du client des réponses claires à trois questions : quel résultat concret il attend, avec quel budget, et pour quelle échéance. Dès que ces trois réponses existent, même sous une forme approximative, vous pouvez rédiger la charte. Elle servira justement à transformer ces réponses approximatives en engagements précis, avec des exclusions et un décideur identifié. Si vous attendez d’avoir toutes les certitudes avant d’écrire, vous n’écrirez jamais rien, car un projet ne devient jamais totalement certain avant d’être terminé.
Une bonne pratique consiste à fixer la rédaction de la charte comme condition de démarrage : aucune heure facturée, aucune tâche assignée, aucun développement lancé avant que la charte ne soit signée. Cette règle simple évite le glissement où le travail commence pendant que le cadrage traîne encore dans les brouillons.
Formuler l’objectif de façon vérifiable
Un objectif de projet mal écrit ressemble à une intention. « Améliorer la présence en ligne du client » n’est pas un objectif, c’est un souhait. Personne ne peut dire, à la fin du projet, si cette phrase a été atteinte ou non, puisqu’elle ne contient aucun critère de vérification. Un objectif utile dans une charte doit permettre à un tiers, qui n’a suivi aucune réunion, de juger seul si le résultat correspond à ce qui était prévu.
Reprenons l’exemple précédent et reformulons-le : « Mettre en ligne un site e-commerce présentant les 40 références de pâtisserie du client, avec paiement en ligne fonctionnel, livré au plus tard le 30 novembre. » Cette phrase contient un résultat précis, un périmètre chiffré, une fonctionnalité nommée et une date. N’importe qui peut vérifier, le 1er décembre, si l’objectif est atteint ou non.
Trois ingrédients rendent un objectif vérifiable. D’abord, un résultat observable : quelque chose que l’on peut voir, tester ou compter, pas une impression. Ensuite, une date : sans échéance, un objectif reste théorique, il n’engage personne dans le temps. Enfin, une condition de succès qui ne dépend pas d’une appréciation subjective : « le client est satisfait » n’est pas vérifiable, « le tunnel de paiement traite une commande test avec succès » l’est.
Voici un exercice simple pour tester la solidité d’un objectif avant de l’inscrire dans la charte : demandez-vous si deux personnes différentes, en lisant la même phrase, pourraient arriver à des conclusions opposées sur la réussite du projet. Si la réponse est oui, l’objectif n’est pas encore assez précis. Réécrivez-le jusqu’à ce que cette ambiguïté disparaisse. Ce travail de reformulation prend dix minutes et évite des semaines de désaccord plus tard.
Le périmètre, et surtout la liste de ce qui en est exclu
Voici la section la plus mal traitée, et paradoxalement la plus utile. On décrit avec soin ce que le projet inclut : les pages du site, les fonctionnalités, les livrables attendus. Puis on s’arrête là, satisfait d’avoir été exhaustif. Le problème, c’est qu’un périmètre décrit uniquement par ce qu’il contient reste une promesse ouverte : rien n’empêche le client de considérer qu’une demande supplémentaire, non mentionnée, « va de soi » et devrait être incluse sans surcoût ni discussion.
C’est précisément par cette faille que les projets débordent. Le client demande une fonctionnalité de traduction en anglais parce que « un site professionnel, aujourd’hui, ça se fait en plusieurs langues ». Personne n’a jamais dit que ce n’était pas inclus, donc personne ne peut refuser fermement sans passer pour de mauvaise foi. La seule protection efficace consiste à écrire, noir sur blanc, ce qui n’est pas dans le projet, au même niveau de détail que ce qui y figure.
Une exclusion bien écrite ne se contente pas de dire « non ». Elle nomme précisément ce qui est laissé de côté, pour qu’il n’y ait pas de zone grise. « Le site ne sera pas traduit » est plus faible que « le site sera livré uniquement en version française ; toute traduction fait l’objet d’un devis complémentaire ». La deuxième formulation ferme la porte tout en laissant une voie claire si le client souhaite malgré tout cette prestation, mais en dehors du périmètre initial.
Le tableau suivant illustre, sur un exemple concret de projet de site e-commerce pour une boulangerie, comment formuler ces exclusions en miroir de ce qui est inclus.
| Inclus dans le périmètre | Exclu du périmètre |
|---|---|
| Catalogue de 40 références de pâtisserie | Catalogue des produits traiteur et de la restauration sur place |
| Paiement en ligne par carte bancaire | Paiement en plusieurs fois et paiement à la livraison |
| Version française du site | Traduction en anglais ou dans toute autre langue |
| Livraison en France métropolitaine | Livraison en Corse, dans les territoires d’outre-mer et à l’international |
| Une heure de formation à l’utilisation du back-office | Assistance téléphonique illimitée après la mise en ligne |
| Intégration avec l’outil de comptabilité déjà utilisé par le client | Migration des données de l’ancien site ou d’un ancien logiciel de caisse |
Chaque ligne de la colonne de droite protège concrètement le projet d’un débordement précis. Sans elle, la demande correspondante finirait par arriver, sous forme de « juste un petit ajustement », et il faudrait soit la refuser dans un climat de tension, soit l’accepter gratuitement au détriment de la marge et du calendrier.
Nommer un décideur unique et définir qui tranche
Une charte peut contenir un objectif parfait, un périmètre limpide et des exclusions bien écrites, et rester malgré tout inefficace si elle ne répond pas à une question simple : qui tranche quand deux personnes ne sont pas d’accord ? Sans un nom précis à cet endroit, chaque désaccord rouvre le projet entier, puisque tout le monde peut légitimement penser avoir voix au chapitre.
Le décideur n’est pas nécessairement la personne la plus haut placée dans l’organigramme. C’est la personne qui a le pouvoir réel d’engager les moyens et d’accepter les conséquences d’un choix. Dans une TPE qui travaille pour un client, il y a en général deux décideurs à nommer : un côté client, souvent le dirigeant ou le responsable qui porte le budget, et un côté prestataire, en général le chef de projet qui pilote l’équipe.
La charte doit préciser le champ de décision de chacun. Le décideur côté client tranche sur les questions de périmètre, de budget et de délai : accepter ou refuser une extension, valider un jalon, décider d’un compromis entre qualité et rapidité. Le décideur côté prestataire tranche sur les questions d’exécution : quelle méthode utiliser, comment répartir le travail dans l’équipe, quel ordre de priorité donner aux tâches techniques. Ce découpage évite qu’une seule personne soit submergée par des décisions qui ne relèvent pas de son rôle, et évite aussi qu’un désaccord technique remonte inutilement jusqu’au client.
Une règle simple à ajouter dans la charte : en cas de désaccord entre plusieurs parties prenantes, la décision du décideur nommé s’applique immédiatement, même si elle ne satisfait pas tout le monde. Le débat peut continuer après, pour ajuster les prochaines décisions, mais le projet ne reste jamais bloqué en attendant un consensus qui n’arrivera peut-être jamais. Cette règle, à elle seule, évite des semaines de blocage sur des projets où quatre ou cinq personnes pensent toutes avoir le dernier mot.
Les parties prenantes, leur rôle réel et ce qu’on attend de chacune
Une charte qui se contente de lister des noms et des fonctions ne dit rien d’utile. Ce qui compte, c’est de préciser pour chaque partie prenante ce qu’on attend réellement d’elle, et surtout si elle a un pouvoir de décision ou seulement un rôle consultatif. Beaucoup de projets s’enlisent parce qu’une personne sans pouvoir de décision se comporte comme si elle en avait un, faute d’avoir vu la charte préciser le contraire.
Un outil utile pour clarifier ces rôles est la matrice RACI, qui distingue qui réalise, qui est responsable, qui doit être consulté et qui doit simplement être informé. Intégrer cette distinction dans la charte, même sans construire un tableau RACI complet, aide à éviter les malentendus les plus fréquents : un responsable marketing qui donne un avis sur les textes n’a pas le même poids qu’un sponsor qui valide le budget.
Reprenons l’exemple du projet de site e-commerce pour illustrer ces rôles de façon concrète.
| Partie prenante | Ce qu’on attend d’elle | Ce qu’elle décide |
|---|---|---|
| Sponsor client (propriétaire de la boulangerie) | Fournir les contenus et les photos, valider chaque jalon | Tranche sur le périmètre et sur le budget |
| Cheffe de projet côté agence | Piloter l’équipe, tenir les délais annoncés | Tranche sur les choix d’exécution technique |
| Développeur back-end | Livrer un tunnel de paiement fonctionnel et testé | Aucune décision de cadrage, exécute les choix validés |
| Graphiste | Livrer les maquettes dans les délais fixés | Propose des options, ne tranche pas seule sur le choix final |
| Responsable marketing du client | Relire les contenus et donner un avis sur le ton | Rôle consultatif uniquement, aucune décision de périmètre |
| Prestataire de paiement en ligne (tiers) | Configurer le compte marchand dans les délais convenus | Aucune décision, exécute sur demande contractuelle |
Ce tableau règle à l’avance une source classique de tension : le jour où le responsable marketing exprime un désaccord sur une couleur ou une formulation, la charte permet de rappeler calmement que son rôle est consultatif, et que la décision finale revient au sponsor. Sans cette clarté écrite en amont, ce genre de désaccord se transforme facilement en blocage.
Les livrables et leurs critères d’acceptation
Un livrable mal défini se reconnaît à une caractéristique simple : personne ne sait dire, le jour de sa remise, s’il est terminé ou non. « Le site web » n’est pas un livrable exploitable dans une charte, car cette formulation ne précise ni son contenu exact ni la façon de juger qu’il correspond à ce qui était attendu. Un livrable utile s’accompagne toujours de critères d’acceptation, c’est-à-dire une liste de conditions objectives qui permettent de dire oui ou non à sa réception.
Pour le projet de site e-commerce, le livrable « site marchand » devient acceptable une fois qu’il remplit des conditions précises : le catalogue affiche les 40 références avec photo et prix, le tunnel de paiement traite avec succès une commande test en carte bancaire, le temps de chargement de la page d’accueil reste inférieur à trois secondes sur mobile, et le site s’affiche correctement sur les navigateurs récents les plus utilisés. Ces quatre critères transforment un livrable flou en un objet que l’on peut vérifier en une heure de test.
Pour suivre l’avancement de ces livrables sans perdre le fil, beaucoup d’équipes s’appuient sur un tableau Kanban, où chaque livrable avance visuellement de « à faire » vers « terminé » en passant par une étape de vérification des critères d’acceptation. Ce mode de suivi, sans être décrit dans la charte elle-même, découle directement du travail de définition fait dans cette section : plus les critères sont précis, plus il devient simple de savoir dans quelle colonne placer un livrable à un instant donné.
Une charte qui liste des livrables sans critères d’acceptation reporte le désaccord au moment de la livraison, ce qui est le pire moment possible pour découvrir qu’on ne s’était pas compris. Écrire les critères en amont, même de façon simple, déplace cette clarification à un moment où elle coûte dix minutes de discussion, plutôt qu’à un moment où elle coûte une semaine de retouches non prévues au budget.
Les jalons, et comment les choisir pour qu’ils signifient quelque chose
Un jalon n’est pas une date posée arbitrairement sur un calendrier pour donner une impression de rythme. Un bon jalon marque un état réel du projet, vérifiable, qui ne peut pas être atteint sans que le travail correspondant soit effectivement fait. « Semaine 4 » n’est pas un jalon. « Maquettes validées par le client » en est un, car soit les maquettes sont validées à cette date, soit elles ne le sont pas, et il n’y a pas de zone intermédiaire confortable.
Le piège classique consiste à découper le projet en tranches de temps égales et à appeler chaque tranche un jalon, sans se demander ce qui doit réellement être vrai à cette date. Ce découpage donne une fausse impression de contrôle : on croit suivre l’avancement du projet, alors qu’on suit simplement le calendrier, ce qui n’a jamais empêché un projet de dérailler.
Pour choisir de bons jalons, demandez-vous à chaque étape ce qui doit être vérifiable à cette date précise, et ce qui se passe si cette condition n’est pas remplie. Si la réponse est « rien de particulier », ce n’est pas un jalon, c’est une date de suivi interne. Construire ce calendrier de jalons de façon rigoureuse rejoint le travail habituel du rétroplanning, où l’on part de la date de livraison finale pour remonter les étapes intermédiaires qui doivent nécessairement être franchies avant.
Pour le projet de site e-commerce, quatre jalons suffisent à couvrir l’ensemble du projet : validation des maquettes le 15 septembre, intégration technique terminée le 15 octobre, site en recette chez le client le 10 novembre, et mise en ligne définitive le 30 novembre. Chacun de ces jalons correspond à un état vérifiable du projet, et un retard sur l’un d’eux a un effet mécanique sur les suivants, ce qui permet de réagir avant que le retard ne devienne invisible jusqu’à la dernière semaine.
Le budget et les moyens engagés, y compris le temps des personnes
Le budget d’un projet ne se résume pas à un montant global facturé au client. Une charte complète précise le mode de facturation choisi, forfait ou temps passé, le taux horaire appliqué si ce mode est retenu, le nombre d’heures estimées pour chaque grande phase, et surtout le temps que les personnes internes vont consacrer au projet, en dehors de ce qui est facturé au client.
Reprenons l’exemple du projet de site e-commerce, facturé au temps passé. Le taux horaire appliqué est de 65 euros. L’équipe estime le projet à 280 heures de travail réparties entre la cheffe de projet, le développeur et le graphiste. Le calcul est direct : 280 heures multipliées par 65 euros donnent un budget de 18 200 euros. Écrire ce calcul dans la charte, plutôt que de se contenter d’annoncer le montant final, permet à tout le monde de comprendre d’où vient le chiffre, et de voir immédiatement l’effet d’un dépassement d’heures sur le montant final.
Le temps des personnes internes mérite une attention particulière, car il disparaît souvent des chartes alors qu’il pèse tout autant sur la rentabilité du projet que le budget facturé au client. Si la cheffe de projet passe cinq heures par semaine en réunions internes non facturées, ce temps doit apparaître quelque part, sinon le projet paraît rentable sur le papier alors qu’il grignote discrètement la marge réelle de l’entreprise. Un plan de charge permet de visualiser, personne par personne, le temps réellement disponible et le temps déjà engagé sur ce projet et sur les autres, ce qui évite de découvrir en cours de route qu’une personne clé est en réalité surchargée sur trois projets en parallèle.
Écrire ces chiffres dans la charte, même de façon simple, transforme le budget d’une intuition en un engagement vérifiable. Si le projet dérive au-delà de 320 heures, par exemple, tout le monde peut immédiatement calculer que le coût correspondant grimpe à 20 800 euros, et décider en connaissance de cause si cette dérive doit être absorbée, facturée en supplément, ou évitée en resserrant le périmètre.
Les risques identifiés au départ, et ce qu’on écrit à leur sujet
Lister des risques sans écrire ce qu’on fait s’ils se réalisent ne sert à rien de plus qu’une liste d’inquiétudes. La charte doit associer à chaque risque identifié une parade concrète, décidée à l’avance, plutôt qu’une réaction improvisée le jour où le problème survient réellement.
Pour prioriser les risques à traiter en premier dans une charte, une matrice d’Eisenhower adaptée aux risques aide à distinguer ce qui est à la fois probable et lourd de conséquences de ce qui reste marginal. Un risque peu probable et sans grand effet ne mérite pas la même attention dans la charte qu’un risque probable et bloquant pour le projet entier.
Pour le projet de site e-commerce, voici comment cette section prend forme concrètement.
| Risque identifié | Effet possible sur le projet | Parade prévue |
|---|---|---|
| Retard de livraison des photos produits par le client | Retard direct sur l’intégration du catalogue | Date limite contractuelle fixée à dix jours après le lancement, sinon le jalon suivant glisse d’autant |
| Choix tardif du prestataire de paiement en ligne | Blocage du développement du tunnel de paiement | Décision exigée avant le deuxième jalon, sans quoi ce jalon est reporté |
| Demandes de fonctionnalités supplémentaires en cours de route | Dérive du périmètre et du budget | Toute demande hors périmètre passe par une demande de changement validée par le décideur |
| Indisponibilité du développeur principal | Ralentissement du développement technique | Un second développeur formé en doublure sur les tâches critiques |
| Sous-estimation du temps de rédaction des contenus | Dépassement du budget d’heures estimé | Heures de rédaction budgétées séparément et suivies chaque semaine |
Ce qui rend cette section utile, ce n’est pas la précision de la prévision, personne ne sait vraiment si le développeur principal tombera malade ou non. Ce qui compte, c’est que la réponse à chaque risque soit déjà décidée avant qu’il ne survienne, ce qui évite de perdre du temps à improviser une solution dans l’urgence, sous pression, au pire moment du projet.
Les hypothèses et les dépendances, la partie que tout le monde oublie
Presque toutes les chartes que l’on croise oublient cette section, ou la réduisent à une ligne vague en fin de document. C’est pourtant l’une des plus utiles, car elle écrit ce sur quoi le projet repose sans que l’équipe n’en garde le contrôle. Une hypothèse est une condition que l’on suppose vraie pour construire le planning et le budget, sans l’avoir vérifiée de façon certaine. Une dépendance est un élément extérieur au projet dont l’avancement dépend, sans que l’équipe ne puisse en accélérer le rythme.
Pour le projet de site e-commerce, plusieurs hypothèses structurent tout le calendrier sans que personne ne les ait formellement vérifiées au moment de la signature. On suppose que le client fournira les textes descriptifs des 40 références avant le 20 septembre. On suppose que la marque de fabrique du client est déjà déposée et qu’aucun conflit de nom ne viendra retarder la mise en ligne. On suppose que l’hébergeur choisi restera disponible et fonctionnel pendant toute la durée du projet.
Les dépendances, elles, concernent des éléments extérieurs au contrôle direct de l’équipe. Le projet dépend de la validation du compte marchand par le prestataire de paiement, un délai qui peut varier de quelques jours à plusieurs semaines selon les dossiers. Il dépend aussi de la disponibilité du nom de domaine souhaité par le client, qui doit être vérifiée avant de промettre une date de mise en ligne.
Écrire ces hypothèses et ces dépendances dans la charte protège l’équipe d’une accusation injuste plus tard : si le nom de domaine souhaité est déjà pris et que cela retarde le projet d’une semaine, ce retard est documenté depuis le départ comme une dépendance externe, et non comme une erreur de planification de l’équipe. Cette distinction, écrite noir sur blanc avant que le problème ne survienne, change complètement la nature de la conversation qui suit.
Comment faire valider la charte, et par qui
Une charte non validée reste un brouillon, quelle que soit la qualité de son contenu. La validation transforme un document de travail en engagement partagé, et c’est cette transformation qui donne à la charte sa force le jour où un désaccord survient. Sans validation formelle, chaque partie peut prétendre n’avoir jamais vraiment accepté ce qui y est écrit.
La validation doit passer par deux personnes précises, et non par un groupe flou : le décideur nommé côté client, et le décideur nommé côté prestataire. Ces deux personnes lisent le document dans son intégralité, posent leurs questions, et donnent leur accord explicite, par écrit, même sous une forme simple comme un e-mail de confirmation ou une signature numérique. Un accord oral pendant une réunion ne suffit pas, car il ne laisse aucune trace consultable plus tard en cas de désaccord sur ce qui avait été convenu.
Dans la pratique, organiser une courte réunion de validation reste la méthode la plus efficace. Le document est envoyé quelques jours avant, chaque partie l’annote de ses questions, puis la réunion sert à trancher les derniers points en suspens plutôt qu’à découvrir le contenu en direct. Rédiger ensuite un compte-rendu de réunion qui acte les modifications apportées et confirme l’accord final donne une trace claire du moment précis où le projet a réellement démarré, avec l’accord des deux décideurs sur la version finale du document.
Une fois validée, la charte doit être accessible à toute l’équipe, pas seulement aux deux décideurs qui l’ont signée. Un développeur qui ignore que la traduction en anglais est explicitement exclue du périmètre risque de commencer ce travail par excès de zèle, ou de promettre au client une réponse qu’il n’a pas le pouvoir de donner. La diffusion de la charte validée fait partie intégrante de sa validation, pas une étape annexe.
Ce qui déclenche une révision de la charte en cours de projet
Une charte figée pour toute la durée du projet, sans aucune possibilité de révision, finit toujours par se déconnecter de la réalité. Un projet évolue, un client change d’avis, un risque identifié se réalise réellement. La question n’est donc pas d’empêcher toute révision, mais de définir à l’avance ce qui justifie d’en ouvrir une, pour éviter que chaque petit ajustement ne remette en cause le document entier.
Quatre événements justifient une révision formelle de la charte. Premièrement, une demande de changement de périmètre qui dépasse un seuil défini à l’avance, par exemple plus de dix heures de travail supplémentaire ou plus de mille euros de budget additionnel. Deuxièmement, un dépassement du budget d’heures estimé au-delà d’un pourcentage fixé, par exemple quinze pour cent au-dessus de l’estimation initiale. Troisièmement, un décalage de délai qui touche un jalon jugé critique dans la charte d’origine. Quatrièmement, l’apparition d’une nouvelle partie prenante avec un pouvoir de décision, comme l’arrivée d’un nouveau responsable côté client qui souhaite revoir certains choix.
Chacun de ces déclencheurs doit être écrit dans la charte elle-même, sous forme de seuils précis plutôt que de formulations vagues comme « en cas de changement important ». Un seuil chiffré évite un débat inutile sur ce qui compte ou non comme un changement suffisant pour justifier une révision.
La révision suit le même chemin que la validation initiale : le changement est documenté, daté, présenté aux deux décideurs, et approuvé explicitement avant d’être appliqué. Une charte révisée plusieurs fois n’est pas un échec, c’est au contraire le signe qu’elle a bien joué son rôle de document vivant, capable d’absorber les changements réels du projet sans jamais perdre sa fonction de cadrage clair.
Une charte complète rédigée, section par section, pour un projet concret de TPE
Voici, section par section, la charte complète du projet pris en exemple tout au long de cet article : la création d’un site e-commerce pour la boulangerie Ferrand, réalisée par l’agence Atelier Kolibri.
Objectif
Mettre en ligne un site e-commerce présentant les 40 références de pâtisserie de la boulangerie Ferrand, avec un système de paiement en ligne fonctionnel, livré au plus tard le 30 novembre.
Périmètre inclus
Catalogue complet des 40 références avec photo et prix, paiement en ligne par carte bancaire, version française uniquement, livraison en France métropolitaine, une heure de formation au back-office pour le client, intégration avec l’outil de comptabilité déjà utilisé par la boulangerie.
Périmètre exclu
Catalogue des produits traiteur et de la restauration sur place, paiement en plusieurs fois ou à la livraison, traduction du site en anglais ou dans toute autre langue, livraison en Corse, dans les territoires d’outre-mer et à l’international, assistance téléphonique illimitée après la mise en ligne, migration des données de l’ancien site.
Décideur
Madame Ferrand, propriétaire de la boulangerie, tranche sur toute question de périmètre et de budget. Julie, cheffe de projet chez Atelier Kolibri, tranche sur toute question d’exécution technique et d’organisation de l’équipe.
Parties prenantes
Madame Ferrand, sponsor cliente. Julie, cheffe de projet. Un développeur back-end. Une graphiste. Le responsable marketing du client, en rôle consultatif. Le prestataire de paiement en ligne, en tant que tiers exécutant.
Livrables et critères d’acceptation
Un site marchand fonctionnel : catalogue des 40 références affiché correctement, tunnel de paiement testé avec succès sur une commande réelle, temps de chargement de la page d’accueil inférieur à trois secondes sur mobile, compatibilité vérifiée avec les navigateurs récents les plus utilisés.
Jalons
Validation des maquettes le 15 septembre. Intégration technique terminée le 15 octobre. Site en recette chez le client le 10 novembre. Mise en ligne définitive le 30 novembre.
Budget et moyens
Facturation au temps passé, taux horaire de 65 euros, 280 heures estimées, soit un budget total de 18 200 euros. Le temps interne non facturé, estimé à 20 heures de coordination sur la durée du projet, est suivi séparément par la cheffe de projet.
Risques
Retard de livraison des photos produits, choix tardif du prestataire de paiement, demandes de fonctionnalités supplémentaires, indisponibilité du développeur principal, sous-estimation du temps de rédaction des contenus, chacun avec sa parade décrite plus haut dans cet article.
Hypothèses et dépendances
Le client fournit les textes descriptifs avant le 20 septembre. Le nom de la marque est déjà déposé sans conflit connu. Le projet dépend de la validation du compte marchand par le prestataire de paiement et de la disponibilité du nom de domaine souhaité.
Validation
Document envoyé le 25 août, questions traitées lors d’une réunion le 28 août, accord écrit donné par Madame Ferrand et par Julie le 29 août. Le projet démarre officiellement le 1er septembre.
Les erreurs qui reviennent et comment chacune se corrige
Certaines erreurs se retrouvent d’un projet à l’autre, presque toujours sous la même forme. Les reconnaître à l’avance permet de les corriger avant qu’elles ne coûtent réellement du temps ou de l’argent.
| Erreur fréquente | Comment elle se corrige |
|---|---|
| Objectif formulé en termes vagues, sans résultat vérifiable | Reformuler avec un résultat mesurable, chiffré si possible, et une date précise |
| Périmètre décrit uniquement par ce qu’il inclut | Ajouter systématiquement une liste explicite de ce qui en est exclu |
| Aucun décideur nommé, arbitrage laissé à un comité | Désigner une seule personne qui tranche, même si un comité continue d’échanger |
| Charte rédigée après le démarrage réel du travail | La rédiger avant le lancement, dès que l’objectif, le budget et le délai sont connus |
| Risques listés sans aucune parade associée | Écrire pour chaque risque l’action prévue si le risque se réalise réellement |
| Charte jamais révisée malgré des changements majeurs en cours de route | Fixer des seuils de révision précis et les appliquer sans exception |
Ces six erreurs partagent un point commun : elles retardent toutes une clarification nécessaire jusqu’à un moment où elle coûte beaucoup plus cher qu’au départ. Corriger ces erreurs ne demande pas plus de compétence, seulement plus de rigueur au moment précis où la charte est rédigée, avant que le projet ne prenne sa propre vitesse.
Traduire la charte dans Djaboo, une fois qu’elle est écrite
Dans Djaboo, un projet porte un nom, un client, une description, un statut, une date de début, une échéance, un mode de facturation, un coût, un taux horaire, un nombre d’heures estimées, et un avancement qui peut se calculer à partir des tâches. Les jalons du projet portent un nom, une description, une date de début, une date d’échéance, un ordre et une couleur, et chaque jalon peut être masqué au client. Les membres de l’équipe sont rattachés au projet. Chaque projet dispose d’un espace de discussion par fils de commentaires, de notes et de fichiers, et chaque fichier peut être rendu visible ou non au client. Les tâches se rattachent au projet et au jalon concernés.
Djaboo ne propose aucun document appelé charte de projet, aucun modèle à remplir et aucun champ dédié au périmètre, aux exclusions ou aux critères d’acceptation. Il n’existe aucun registre des risques dans l’outil. Il n’existe aucune étape de validation formelle d’un projet : personne ne signe ni n’approuve quoi que ce soit dans Djaboo.
La méthode qui fonctionne consiste à écrire la charte dans un document à part, avec les sections détaillées dans cet article, puis à traduire son contenu dans Djaboo une fois qu’elle est validée. L’objectif et le périmètre trouvent leur place dans la description du projet. Les étapes deviennent des jalons, dans l’ordre défini, avec leurs dates de début et d’échéance. Le budget se traduit dans le coût du projet et dans les heures estimées, selon le mode de facturation choisi. Les responsables identifiés dans la charte deviennent des membres rattachés au projet, puis des personnes assignées aux tâches correspondantes.
Pour que la charte reste vivante plutôt que de dormir dans un dossier oublié, une pratique simple consiste à programmer sa relecture comme une tâche récurrente dans Djaboo, par exemple toutes les deux semaines, rattachée au projet. Cette tâche ne remplace pas le document de cadrage lui-même, mais elle rappelle régulièrement de vérifier que le projet suivi dans l’outil correspond encore à ce qui avait été décidé au départ, et de déclencher une révision si l’un des seuils fixés dans la charte est franchi.
Une charte de projet ne se juge jamais sur la qualité de son objectif ni sur le nombre de pages consacrées aux livrables. Elle se juge sur la précision de ce qu’elle exclut, car c’est cette liste, et elle seule, qui empêche le projet de déborder silencieusement demande après demande.
Elle se juge aussi sur une seule ligne, souvent la plus courte du document : le nom de la personne qui tranche en cas de désaccord. Sans cette ligne, chaque tension rouvre le projet entier et transforme un document de cadrage en simple souvenir de ce qui avait été espéré au départ.
