REVENDICATIONS 1. Procédé développement de projets informatiques (P1, P2) destinés à être mis oeuvre par un système informatique, procédé comprenant une phase d'analyse fonctionnelle (601) en vue de recenser les fonctionnalités devant être assurées, une phase de création de composants (C1, C2) du projet à l'aide de moyens informatiques pour remplir lesdites fonctionnalités et une phase de déclaration sur ce même système des composants créés lors de la phase de création en vue de leur chargement dans une zone de mémoire du système et de leur mise en oeuvre le système, caractérisé ce que # lors phase de création de composants, chaque fonctionnalité est entièrement remplie par le composant qui lui est associé, et # lors phase de déclaration des composants, chaque composant créé déclaré auprès d'un composant de chargement du système, et en ce # lors de mise en couvre des composants dans le système, le chargement d'un composant dans une zone de mémoire du système nécessite l'appel de la fonctionnalité remplie par ledit composant par un autre composant du système, et # les ressources du système utilisées par un composant sont automatiquement libérées lorsque ledit composant n'est pas utilisé, de sorte que seules les ressources du système effectivement nécessaires à la réalisation des fonctionnalités identifiées lors de la phase d'analyse fonctionnelle sont mobilisées. 2. Procédé selon la revendication précédente, caractérisé en ce que lors de la création d'un composant on procède aux étapes suivantes # création (602) d'un fichier source d'interface du composant, en vue de constituer une partie interface (INT) du composant, # création (603) d'au moins un fichier source de code permettant réaliser la fonctionnalité du composant, en vue de constituer partie implémentation (IMP) du composant. 3. Procédé selon la revendication précédente, caractérisé en ce chaque composant peut remplir la fonctionnalité qui lui est associée mettant en couvre des moyens logiciels, et/ou matériels. 4. Procédé selon la revendication 2 ou 3, caractérisé en ce que le fichier d'interface de chaque composant comprend une description de la fonctionnalité remplie par ledit composant, indépendante de la manière dont cette fonctionnalité est remplie par le composant. 5. Procédé selon la revendication précédente, caractérisé en ce que le fichier d'interface comprend également une description des fonctionnalités que le composant a besoin d'importer d'autres composants afin de remplir sa propre fonctionnalité. 6. Procédé selon la revendication précédente, caractérisé en ce que lors de la création d'un composant on procède également aux étapes suivantes # création (604) d'un Makefile dans lequel sont spécifiés le(s) langage(s) utilisé(s) pour le(s) fichier(s) source créé(s) lors l'étape de création de fichier(s) source de code, le(s) fichier(s) source de code correspondant à la partie implémentation du composant, # création (605) d'un prototype du composant, # édition de liens (606) entre la partie interface et la partie implémentation du composant, pour générer un prototype de composant exécutable. # mise en oeuvre du makefile (609) pour compiler le composant individuellement, et constituer un fichier objet respectif pour le fichier source d'interface de la partie interface du composant ainsi que pour le ou chaque fichier source de code de partie implémentation du composant, # encapsulation (610) des fichiers objets créés lors de l'étape précédente dans un module exécutable unique. 7. Procédé selon la revendication précédente, caractérisé en ce que lors de la création du prototype d'un composant on crée un prototype comprenant une interface objet résultant de la compilation du fichier source d'interface du composant, un fichier objet prototype pour chaque fichier source de code de la partie implémentation du composant. 8. Procédé selon la revendication précédente, caractérisé en ce que lors de la compilation du fichier source d'interface du composant, on procède à l'analyse et la vérification de la cohérence du fichier source de l'interface, la traduction du fichier source de l'interface en données binaires, la génération automatique d'au moins un fichier pour appeler les fonctionnalités devant être importées par le composant. 9. Procédé selon l'une des revendications 6 à 8, caractérisé en ce que après l'étape d'édition de liens entre la partie interface et la partie implémentation du composant pour générer un prototype de composant exécutable, on procède à une étape (607) de test d'intégrité automatique lors duquel on vérifie que le projet est cohérent fermé. 10. Procédé selon la revendication précédente, caractérisé en que lors du test d'intégrité automatique, pour chaque fonctionnalité nécessaire au projet on recherche automatiquement, parmi une liste de composants accessibles, un composant qui remplit ladite fonctionnalité. 11. Procédé selon la revendication précédente, caractérisé en ce que dans le cas où on identifie plusieurs composants remplissant la fonctionnalité demandée, on peut choisir entre ces composants un composant particulier. 12. Procédé selon la revendication 10 ou 11, caractérisé en ce que dans le cas où test d'intégrité révèle que le projet n'est pas correctement fermé, édite un message d'erreur indiquant les incohérences pour pouvoir modifier certains composants et/ou en ajouter. 13. Procédé selon l'une des revendications 6 à 12, caractérisé en ce que pour chaque composant chargé dans le système, la description des fonctionnalités que le composant a besoin d'importer d'autres composants afin de remplir sa propre fonctionnalité est accessible en permanence aux autres composants du système, 14. Procédé selon l'une des revendications 6 à 13, caractérisé en ce que lors de l'encapsulation (610) des fichiers objets créés lors de l'étape précédente dans un module exécutable unique, on vérifie que toutes fonctionnalités fournies par les différents parties d'interface du projet été effectivement décrites totalement dans un fichier source associé, compilées. 15. Procédé selon l'une des revendications 6 à 14, caractérisé en ce que le procédé comprend la mémorisation dans une zone de mémoire vive du système d'une cartographie (G) des composants chargés dans le système. 16. Procédé selon la revendication précédente, caractérisé en ce que ladite cartographie est destinée à être consultée lors de l'appel d'une fonctionnalité par un composant appelant, pour déterminer si un composant de ladite cartographie est apte à fournir la fonctionnalité appelée. 17. Procédé selon l'une des revendications 15 ou 16, caractérisé en ce que ladite cartographie est mise à jour en temps réel lors du fonctionnement du système, en fonction des composants chargés dans le système.