Actuellement, la réponse écrite dans la FAQ est la suivante :
1. Le fichier d'en-tête de la déclaration de la classe ;
2. les fichiers standards (STL) ;
3. les fichiers d'en-tête de l'O.S. ;
4. les fichiers d'en-tête des bibliothèques tierces (boost, xml, wxWidget…) ;
5. les fichiers d'en-tête de mes bibliothèques externes ;
6. les fichiers d'en-tête de mon projet.

Cet ordre est une proposition parmi d'autres qui ont aussi leur légitimité. Vous pouvez suivre un autre ordre d'inclusion si vous en sentez le besoin compte tenu de vos pratiques habituelles ou du contexte de votre application. En fait, l'idée maîtresse est de maintenir une cohérence sur l'ensemble du projet. Quelle que soit la politique que vous choisissez de mettre en ouvre, utilisez la même systématiquement dans tous vos fichiers.
Lien : http://cpp.developpez.com/faq/cpp/?p...iers-d-en-tete

Je suis en désaccord avec cette réponse et je propose la réponse suivante :

Dans un fichier ".cpp", par exemple "Toto.cpp", inclure dans l'ordre :
  1. un éventuel entête précompilé (par exemple "stdafx.h" si vous utilisez Visual C++) ;
  2. le fichier d'entête de la déclaration de la classe (typiquement "Toto.h") ;
  3. les fichiers d'entête du projet ;
  4. les fichiers d'entête du groupe de projets ;
  5. les fichiers d'entête des bibliothèques externes ;
  6. les fichiers d'entête des bibliothèques tierces qui incluent des entêtes de l'OS ;
  7. les fichiers d'entête de l'O.S. ;
  8. les fichiers d'entête des bibliothèques tierces qui n'incluent aucun entête de l'OS ;
  9. les fichiers standards (STL) ;


Dans un entête, par exemple "Toto.h", inclure dans l'ordre :
  1. les fichiers d'entête du projet ;
  2. les fichiers d'entête du groupe de projets ;
  3. les fichiers d'entête des bibliothèques externes ;
  4. les fichiers d'entête des bibliothèques tierces qui incluent des entêtes de l'OS ;
  5. les fichiers d'entête de l'O.S. ;
  6. les fichiers d'entête des bibliothèques tierces qui n'incluent aucun entête de l'OS ;
  7. les fichiers standards (STL) ;


L'idée est d'aller du plus local vers le plus général pour maximiser les chances de détecter les oublis dans les entêtes.

Par exemple, admettons que "Toto.h" ait besoin d'inclure "Titi.h", un entête du même projet, mais a oublié de le faire. Pour que l'erreur soit détectée, il suffit qu'un fichier ".cpp" inclut (directement ou indirectement) "Toto.h" avant d'inclure "Titi.h".
Si "Toto.cpp" inclut "Toto.h" juste après avoir inclus l'éventuel entête précompilé alors, le seul cas où l'erreur n'est pas détectée, c'est celui où l'éventuel entête précompilé inclut "Titi.h".

Pour prolonger l'exemple, admettons que "Toto.h" ait besoin d'inclure, en plus de "Titi.h" (un entête du même projet), "Groupe.h", un entête du même groupe de projets. Admettons aussi que "Titi.h" ait besoin d'inclure lui aussi "Groupe.h" mais a oublié de le faire, et que le "Titi.cpp" ne suive pas les conventions d'inclusions et inclut "Groupe.h" avant d'inclure "Titi.h", ce qui masque l'erreur.
Si "Toto.h" inclut les entêtes du projet avant ceux du groupe de projets, donc inclut "Titi.h" avant d'inclure "Groupe.h", l'erreur sera détectée à la compilation de "Toto.cpp", sauf si "Groupe.h" appartient à l'éventuel entête précompilé inclus par "Toto.cpp".

Remarque : S'il n'y a aucun entête précompilé, il suffit que chaque fichier ".cpp" inclut en premier son fichier d'entête correspondant pour que la compilation garantisse qu'il ne manque aucune inclusion et aucune déclaration dans les fichiers d'entête.

EDIT 19/09/2016 vers 14h46 : En fait, l'ordre entre "les fichiers d'entête de l'O.S." et "les fichiers d'entête des bibliothèques tierces qui n'incluent aucun entête de l'OS" n'a pas d'importance, tant que aucun ne fait des inclusions de l'autre.