Dépendances du diagramme de Gantt expliquées : FS, SS, FF et SF

Les quatre types de dépendances du Gantt sont finish-to-start, start-to-start, finish-to-finish et start-to-finish. Utilisez la relation la plus faible qui représente fidèlement l’œuvre.

GanttFather
Mis à jour 7 août 2026 13 min read
View as Markdown
The short answer

Les quatre types de dépendances du Gantt sont finish-to-start, start-to-start, finish-to-finish et start-to-finish. Utilisez la relation la plus faible qui représente fidèlement l’œuvre.

Que sont les dépendances dans un diagramme de Gantt ?

Une dépendance est une relation logique entre deux tâches. Il indique quand une tâche peut commencer ou se terminer par rapport à une autre. Les quatre types de relations standard sont finish-to-start (FS), start-to-start (SS), finish-to-finish (FF) et start-to-finish (SF).

Les dépendances font qu’un diagramme de Gantt se comporte comme un planning. Lorsqu’un prédécesseur déménage, le moteur de planification peut recalculer ses successeurs au lieu de laisser chaque date être réparée manuellement.

Utilisez la relation la plus faible qui décrit avec précision le travail. N’ajoutez pas un lien finish-to-start simplement pour garder les barres bien rangées ; chaque lien doit représenter un véritable transfert technique, physique, réglementaire ou informationnel.

Les quatre types de dépendances en un coup d’œil

TapezSignificationExemple simple
Fin au début (FS)Le successeur ne peut pas démarrer tant que le prédécesseur n’a pas terminéLes tests commencent une fois la construction terminée
Du début au début (SS)Le successeur ne peut pas démarrer tant que le prédécesseur n’a pas démarréLa prise de notes commence au début de l’atelier
Fin à fin (FF)Le successeur ne peut pas terminer tant que le prédécesseur n’a pas terminéLa relecture finale ne peut pas être terminée avant la fin de l’écriture
Du début à la fin (SF)Le successeur ne peut pas terminer avant le démarrage du prédécesseurL’ancienne équipe de support ne peut pas se terminer tant que la nouvelle équipe n’a pas commencé

« Prédécesseur » désigne la tâche fournissant la contrainte. « Successeur » signifie que la tâche est contrainte. Ces mots ne signifient pas nécessairement que le prédécesseur dans son intégralité doit se produire en premier – cela dépend du type de relation.

1. Fin au début (FS)

B ne peut pas commencer tant que A n’a pas terminé. Il s’agit de la relation la plus courante.

Exemples :

  • Déployer en production une fois les tests d’acceptation terminés.
  • Couler le béton une fois l’inspection du coffrage terminée.
  • Envoyez des invitations une fois la liste des invités approuvée.
  • Démarrez la migration des données une fois la sauvegarde terminée.

Si « Approuver la conception » se termine mardi et que « Interface de construction » a un lien FS, la construction peut commencer au prochain temps de travail disponible selon les règles du calendrier de l’outil.

FS est facile à comprendre, mais en abuser sérialise le travail. Demandez si le successeur a vraiment besoin de chaque élément du prédécesseur. Si le développement peut commencer lorsque la première spécification approuvée est disponible, une décomposition différente peut créer un chevauchement plus réaliste.

2. Du début au début (SS)

B ne peut pas démarrer tant que A n’a pas démarré. Les tâches peuvent alors se poursuivre pendant des durées différentes.

Exemples :

  • Commencez les notes de réunion lorsque la réunion commence.
  • Commencer le suivi qualité dès le démarrage de la production.
  • Commencer le transport d’excavation dès le début de l’excavation.
  • Démarrez la couverture du support client dès le début d’un lancement.

SS ne signifie pas que les deux tâches doivent démarrer exactement au même instant, sauf s’il n’y a pas de décalage et que le calendrier est contraint de cette façon. Il détermine le début le plus précoce autorisé du successeur.

3. Fin à fin (FF)

B ne peut pas terminer tant que A n’a pas terminé. La relation contrôle l’achèvement et non le démarrage.

Exemples :

  • L’édition ne peut pas se terminer tant que l’écriture n’est pas terminée.
  • La surveillance de la sécurité ne peut pas être terminée avant la fin de la migration.
  • La surveillance du chantier ne peut pas être terminée avant la fin des travaux.
  • Le rapprochement des factures ne peut pas être terminé avant que toutes les factures soient reçues.

FF est utile lorsque deux activités s’exécutent en parallèle mais que l’une doit rester active jusqu’à la fin de l’autre. Il ne doit pas être utilisé pour cacher un livrable peu clair. S’il existe un transfert final, un jalon distinct peut mieux communiquer la logique.

4. Du début à la fin (SF)

B ne peut pas terminer tant que A n’a pas commencé. Ceci est valide mais rare.

L’exemple classique est la couverture des équipes : l’équipe sortante ne peut pas se terminer tant que l’équipe entrante n’a pas commencé. D’autres exemples incluent :

  • un système existant ne peut pas être mis hors service avant le démarrage du service de remplacement ;
  • la surveillance temporaire ne peut s’arrêter avant le début de la surveillance permanente ;
  • la couverture de l’ancien fournisseur ne peut prendre fin tant que le nouveau fournisseur n’a pas commencé le service.

Les équipes utilisent souvent SF de manière incorrecte car sa formulation semble inversée. Nommez à haute voix le prédécesseur et le successeur : « La fin de l’ancienne équipe dépend du début de la nouvelle équipe. » Si cette phrase n’est pas vraie, utilisez une autre relation ou repensez les tâches.

Que sont le décalage et l’avance ?

Lag est une période d’attente ajoutée à une dépendance. Lead permet un chevauchement et est souvent représenté comme un décalage négatif.

Exemples :

  • FS + 2 jours : Appliquer la deuxième couche deux jours après la fin de la première couche.
  • SS + 1 jour : Commencez la transcription un jour après le début des entretiens.
  • FS − 2 jours : Commencez la révision deux jours avant la fin de la rédaction.

Le décalage doit représenter un véritable temps de travail ou écoulé, comme le durcissement, l’expédition ou une période de préavis obligatoire. Évitez d’utiliser un décalage inexpliqué comme un seau pour un travail caché. Si quelqu’un doit effectuer une action pendant l’intervalle, modélisez cette action comme une tâche avec un propriétaire.

Lead peut rendre un calendrier fragile car il suppose que la sortie partielle du prédécesseur sera prête. Diviser le prédécesseur en livrables plus petits, par exemple « Projets de sections 1 à 3 » – crée souvent une logique plus claire qu’un décalage négatif important.

Un exemple de dépendance travaillée

Considérons une petite version logicielle :

TâcheDuréeRelation
Implémenter la fonctionnalité8 jours
Rédiger des cas de tests5 joursSS avec implémentation
Exécuter des tests4 joursFS après la mise en œuvre et les cas de test
Sortie du moniteur2 joursSS avec la version de production
Mettre fin à la couverture de restauration0 joursSF après le démarrage de la surveillance

La rédaction des cas de test commence par la mise en œuvre car le testeur peut travailler à partir de la conception convenue. L’exécution attend à la fois les cas d’implémentation et de test. La surveillance commence dès la sortie. Le dernier exemple SF indique que la couverture de restauration temporaire ne peut pas prendre fin tant que la surveillance n’a pas commencé ; en pratique, un jalon plus clair ou une chaîne FS peut encore être préférable.

Comment les dépendances affectent-elles le chemin critique ?

Le réseau de dépendances détermine quelles chaînes peuvent contrôler la date de fin. Une passe avant trouve les dates les plus anciennes ; un passage en arrière trouve les dernières dates et flotte. Les tâches sans flexibilité de planification constituent un chemin critique selon les règles du modèle.

Les liens manquants font flotter le travail de manière indépendante et peuvent créer une date de fin sans support logique. Des liens redondants ou trop restrictifs peuvent créer un calendrier plus long que ce que nécessite le travail. Passez en revue les deux extrêmes avec le liste de contrôle de la qualité du calendrier du projet.

Comment choisir la bonne relation ?

Posez deux questions :

  1. Quel événement dans le prédécesseur est important : son début ou sa fin ?
  2. Quel événement du successeur est contraint : son début ou sa fin ?

Cela produit le code à deux lettres. Demandez-vous ensuite si le décalage est une véritable période d’attente et si des tâches plus petites expliqueraient mieux le transfert.

Dans l’application de GanttFather, les dépendances peuvent utiliser des relations FS, SS, FF ou SF avec décalage. Le lien visuel apparaît sur le diagramme de Gantt et les modifications du planning peuvent se propager via les tâches liées. Utiliser Comment lire un diagramme de Gantt pour revoir le résultat.

Comment modéliser les dépendances dans GanttFather ?

Connectez un prédécesseur à son successeur, choisissez FS, SS, FF ou SF et ajoutez du décalage lorsqu’une attente ou un chevauchement réel existe. Déplacez ou redimensionnez le prédécesseur pour confirmer que le successeur réagit comme prévu, puis activez le chemin critique pour voir si ce lien permet de contrôler la fin du projet.

La propagation des dépendances prouve la séquence logique, et non la faisabilité des ressources. GanttFather n’effectue pas automatiquement les affectations au niveau des ressources, donc inspectez tout propriétaire réservé sur des tâches liées qui se chevauchent et résolvez le conflit manuellement.

Créez un projet GanttFather gratuit et testez le réseau de dépendances avec un exemple de chaque relation dont votre plan a réellement besoin.

Questions fréquemment posées

Quelle est la dépendance du Gantt par défaut ?

La plupart des outils de planification utilisent par défaut finish-to-start car c’est courant et intuitif. Un défaut ne constitue pas une preuve ; changez-le lorsque le travail nécessite une relation différente.

Une tâche peut-elle avoir plusieurs prédécesseurs ?

Oui. Un test peut nécessiter du code, un environnement et des données de test approuvées. Son démarrage au plus tôt est régi par la contrainte du prédécesseur qui se termine au plus tard après prise en compte des calendriers et du décalage.

Les dates d’échéance sont-elles dépendantes ?

Non. Une date d’échéance est un objectif ou une contrainte. Une dépendance décrit l’ordre logique entre les tâches. Utilisez la logique pour calculer les dates, puis comparez les prévisions avec l’objectif.

Les tâches récapitulatives doivent-elles avoir des dépendances ?

Liez généralement les activités détaillées ou les jalons où le transfert a lieu. Les liens sur les tâches récapitulatives et enfants peuvent créer des contraintes confuses ou en double. Utilisez les liens récapitulatifs uniquement lorsque votre méthode et votre outil de planification les gèrent de manière prévisible.


Sources

  1. Support Microsoft, Comment Project planifie les tâches : en coulisses
  2. Project Management Institute, PMI Lexique des termes de gestion de projet
  3. Bureau de responsabilité du gouvernement des États-Unis, Guide d’évaluation des horaires

Want to skip the reading?

GanttFather is free forever — no card, no trial.

Start free
Next up
GanttFather
The Don of Project Management

Every feature included — Gantt, Kanban, dependencies, critical path, real-time sync, Excel and AI agents. Free tier includes 1 project you own, 2 editor seats, and unlimited viewers and guests.

Start free