Espace topologique projet

 

En mémoire de mon ami Pierre, désormais disparu, qui avait pour habitude de commencer nos longues conversations par cette formule : « Donnons-nous un ouvert et discutons. »
Puis, nous lancions une question ouverte et nous étions partis pour quelques heures de réflexion.

 

Pour ceux qui sont intéressés par les fondements mathématiques sous-jacents à la méthode JET, voici les bases sur lesquelles j'ai bâti cette méthode.

Concrètement, ce n'est pas un problème de s'éloigner un peu de la rigueur imposée par cette base mathématique, mais il est important d'en garder l'esprit.

Les idées qui m'ont conduit à concevoir la notion d'« espace projet » sont finalement d'une grande simplicité. Les questions associées à ces idées sont les suivantes :

• Quelles sont les structures élémentaires, les boîtes à outils, si elles existent, sur lesquelles l'ensemble des projets pourraient reposer : les bases de la gestion de projet ?
• Existe-t-il un espace de travail idéal pour diriger les projets ? 
• Que veut dire atteindre un objectif ? Comment peut-on évaluer cette atteinte ?
• Comment conceptualiser l'environnement d'un projet ?
• Quelle est la nature d'une relation dans le contexte d'un projet ?

 

Les interrogations qui ont véritablement conduit à l'émergence de l'« espace projet » sont les suivantes : Quels sont les atomes de gestion de projet : les briques élémentaires ? Comment opérer avec elles ?

 

Les sections suivantes vont montrer comment j'ai répondu à ces questions.

Comme vos connaissances en mathématiques, en particulier en topologie générale, remontent peut-être à plusieurs dizaines d'années et que nous devons être rigoureux lorsque nous les utilisons, je me suis permis de rappeler quelques définitions.

 

Les atomes : les caractéristiques projet

 

La première démarche que nous entreprenons lors de l'initiation d'un projet consiste à rassembler des informations le concernant.

Pensons, un instant, à la possibilité, purement théorique, de recueillir de manière exhaustive toutes ses données, voire toutes les données des projets en cours de réalisation ou déjà réalisés.

Pourquoi cette idée saugrenue ? La tendance actuelle dans le domaine du traitement des informations est de collecter un maximum de données sur un domaine (Data Mining) et de les passer à la moulinette de l'apprentissage machine (Machine Learning), voire de façon plus particulière avec de l’apprentissage profond (Deep Learning).

 

Effectivement, les modèles CNN (Convolutional Neural Networks) ont grandement évolué et permettent maintenant d’atteindre des performances de classification d’images et d'autres objets numériques de manière parfois supérieure à celles d’experts humains (dans la mesure où un nombre suffisant d’exemples est disponible pour entraîner le modèle).

Les modèles de transformers supplantent leurs prédécesseurs en performances prédictives, notamment sur d’autres problématiques telles que le traitement du langage naturel, la production, la traduction et la génération de texte, la localisation d'objets dans les images, etc.

Avec, par exemple, des méthodes de réduction de dimensionalité, il est possible de projeter dans un espace de visualisation en deux ou trois dimensions des informations complexes, ce qui permet une analyse humaine beaucoup plus directe du jeu de données. Dans cet espace, l'analyse de voisinages est possible : les zones représentées par des points proches auront des contenus similaires et des points éloignés correspondront à des contenus moins similaires.

N'est-ce pas ce que nous voulons ? Oui, faut-il encore, pour cela, extraire des données de projets présentées de manière relativement semblable pour en extraire les règles générales de gestion. Sinon, nous collecterons uniquement des analyses et des exposés, comme celui-ci, de méthodes de gestion de projet. Certainement qu'une analyse de l'état de l'art, par ce moyen, dans le domaine de la gestion de projet serait très utile, mais cela n'est pas l'objectif ici.

Les modèles existants d'apprentissage ne sont pas encore suffisamment puissants pour sortir du paradigme de l'analyse par corrélation. Même si, à ma grande surprise, certains résultats sont bluffants. Mais, lorsque des questions subtiles sont posées à ces machines, le vide sémantique se fait jour. De toutes les façons, je n'ai ni l'envie ni les moyens de me lancer dans cette voie de recherche.

« Trop d'informations tuent l'information », même si cet adage semble être mis en brèche par l'apprentissage machine, pour un humain, cela me parait encore vrai. La connaissance d'un domaine dépend davantage des représentations mentales et de leurs pratiques que de la quantité de connaissances et de savoir-faire acquis, même si ceux-ci doivent être en nombre suffisant pour la qualification de maîtrise.

Je crois encore nécessaire de suggérer une méthode plus traditionnelle de structuration et d'analyse des données projet afin de laisser les directeurs de projet autonomes face aux outils automatiques, leur permettant ainsi d'avoir, en eux, un modèle de représentation de projet pour le piloter.

 

Établissons à présent les fondements des structures et des représentations de projet qui sous-tendent la méthode JET

Je ne considère pas qu'il soit judicieux de rechercher la complétude des informations relatives à un projet. Cette approche pourrait conduire à une gestion des complications plutôt qu'à celle de la complexité du projet. Cette évaluation aboutira à la sélection des caractéristiques pertinentes pour ce projet, c'est-à-dire valables. Cette analyse est l'objet de la première étape de la méthode JET.

Concevons l'ensemble P d'informations qui contient toutes les caractéristiques pertinentes pour le projet. Il est indéniable que cet ensemble va évoluer tout au long du projet, mais cela n'affecte en rien ce qui suit. Il est par conséquent envisageable et recommandé d'initier l'établissement des structures de gestion du projet dès le commencement de la collecte des informations relatives à celui-ci.

 

Une caractéristique est une information primaire, qui concerne le projet et son environnement, qu'elle soit descriptive ou numérique. La reconnaissance de la pertinence d'une information en lien avec le projet constitue l'essence même de la méthode JET. Un ensemble projet P se définit comme un ensemble fini de caractéristiques pertinentes pour le projet. L'ensemble des parties de l'ensemble projet P est noté P(P), aussi appelé ensemble puissance de P.  Card(P(P)) = 2Card(P) Cardinalité : si P a n éléments, alors P(P) aura 2n éléments. L'ensemble puissance projet contient par définition l'UN et le TOUT. L'UN, en effet, car l'ensemble ne contenant qu'une seule caractéristique {c} en est un élément et le TOUT parce que P lui-même y est aussi inclus. Il contient aussi le RIEN, l'ensemble vide \(\Phi\).

 

Les relations : les représentations projet

 

À présent que nous disposons d'un ensemble de caractéristiques du projet, il est nécessaire de les interconnecter et de représenter ces relations afin d'en faire ressortir un sens.

Tout d'abord, (re)examinons les définitions de produit cartésien, de relation, d'application, de famille et de matrice qui nous seront utiles ultérieurement.

Produit cartésien

Étant donné deux ensembles E et F, on appelle produit cartésien de E et F l’ensemble suivant :

E\(\times\)F = {(x, y) : x \(\in\) E et y \(\in\) F}

et le produit cartésien de n ensembles avec \({I}\) = {1,... n} par

\(\displaystyle \prod_{i\in I}E_{i}\) = {(x₁, x₂, . . . , x_n) : x₁ \(\in E_{1}\) et x₂ \(\in E_{2}\) et ... et x_n \(\in E_{n}\)}.

Plus généralement, on introduit des n-uplets (ou n-listes) (couples, triplets, quadruplets, quintuplets, sextuplets, heptuplets, octuplets, nonuplets, décuplets…) (x₁, x₂, . . . , x_n) avec la propriété :

(x₁, x₂, . . . , x_n) = (y₁, y₂, . . . , y_n) ⇔ x₁ = y₁ et x₂ = y₂ . . . x_n = y_n 

 

Ce produit n'est pas commutatif, c'est-à-dire que E\(\times\)F peut être différent de F\(\times\)E. Par conséquent, un n-uplets est une liste ordonnée, donc l’ordre des éléments dans la liste est peut-être important. Il est à remarquer qu'il n'est pas utile d'introduire des relations d'ordre pour avoir un outil pour créer des listes ordonnées, le produit cartésien suffit.
Lorsque E et F sont deux ensembles finis, alors le cardinal (nombre d'éléments) de E\(\times\)F est le produit du nombre d'éléments de E et du nombre d'éléments de F : Card(E\(\times\)F)=Card(E)×Card(F).

Ne pas confondre une paire {x,y} une partie de P(E) qui est un ensemble non ordonné de deux éléments d'un même ensemble E avec un couple (x,y) élément de E\(\times\)F (ou de E\(\times\)E) ordonné de deux éléments de E et de F (ou de E aussi).

 

Une relation

Une relation R est la donnée de :
– Un ensemble de départ : E (non vide).
– Un ensemble d’arrivée : F (non vide).
– D'un graphe G qui est une partie de E\(\times\)F ( G \(\subset\) E \(\times\) F).
Soient x \(\in\) E et y \(\in\) F, on dira que x est en relation avec y pour R lorsque (x, y) ∈ G, on écrira x R y. On dira que y est une image de x par R et que x est un antécédent de y par R.
Lorsque tout élément de E a une et une seule image par R, on dit que R est une application (ou fonction). Si c’est le cas, et si x R y, alors on écrira plutôt y = R(x), on dira que y est l’image de x par R. L’ensemble des applications de E vers F est noté F(E, F) ou encore F^E.

 

L'intérêt principal de connaître des caractéristiques de projet est de pouvoir les mettre en relation entre elles. Concrètement, former un couple (ci , ai) composé d'une caractéristique (primaire) ci \(\in\) P et d'un attribut (caractéristique secondaire) ai \(\in\) P qui lui est associé. Ce qui revient à travailler sur un graphe G \(\subset\) P2 = P\(\times\)P, représentant la relation ci R ai de lien d'attribut. Il n'est pas utile d'introduire des relations d'ordre pour avoir un outil pour créer des listes ordonnées de caractéristiques projet, donc de priorisation, le produit cartésien suffit. Nous analyserons les situations de projet avec des graphes G, bien choisis, que j'appelle des représentations projet.

 

Composée de fonction

Soient E, F, G trois ensembles, f : E → F et g : F → G deux applications. La composée g ◦ f est l’application de E vers G définie par : ∀x \(\in\) E, (g ◦ f )(x) = g(f (x))

g ◦ f : E → G
x \(\mapsto\) (g ◦ f )(x) = g(f (x))

 

Famille d’éléments d’un ensemble indexée

Soit \({I}\) un ensemble, et soit E un ensemble. On appelle famille d’éléments de E indexée par \({I}\) toute application u : \({I}\) → E, on note généralement cette famille (u\(_{i}\))\(_{i∈I}\), et pour \({i\in I}\), on note u(i) = u\(_{i}\) (appelé terme d'indice \({i}\)). L’ensemble de départ \({I}\) est appelé ensemble des indices de la famille.
Une famille d’éléments de E indexée par \(\mathbb{N}\) est appelée suite d’éléments de E. L’ensemble des familles d’éléments de E indexées par \({I}\) se note F(\({I}\), E) ou E\(^{I}\).

La notion de famille est une généralisation de celle de suites numériques.
Si \({J}\) \(\subset\) \({I}\), la restriction de l'application u à \({J}\) est appelée sous-famille de la famille u.

 

Famille de parties d’un ensemble indexée

Conformément à la définition ci-dessus, une famille de parties de E indexée par un ensemble \({I}\), est une application A : \({I}\) →P(E), que l’on peut noter (A\(_{i}\))\(_{i∈I}\) (A\(_{i}\) étant une partie de E pour tout \({i\in I}\)). On peut alors généraliser les notions d’intersection et de réunion de la manière suivante :

– La réunion de la famille (A\(_{i}\))\(_{i∈I}\) est     \(\bigcup_{i∈I}\)A\(_{i}\)= {x \(\in\) E | ∃\({i\in I}\), x \(\in\) A\(_{i}\)}.
– L’intersection de la famille (A\(_{i}\))\(_{i∈I}\) est \(\bigcap_{i∈I}\)A\(_{i}\)= {x \(\in\) E | ∀\({i\in I}\), x \(\in\) A\(_{i}\)}.

  

Projection d'une famille d'ensembles 

Soit (A\(_{i}\))\(_{i∈I}\) une famille d’ensembles indexée par \({I}\) = {1,... n} et X le produit cartésien de cette famille X = \(\displaystyle \prod_{i\in I}A_{i}\)
Pour tout \({i\in I}\), l’application p\(_{i}\) : X → A\(_{i}\), définie par p\(_{i}\)(x) =a\(_{i}\) avec x = (a\(_{1}\), a\(_{2}\), . . . , a\(_{n}\)) est appelée la projection de X sur le facteur d’indice \({i}\).

 

Matrice

Une matrice de type (I,J) à coefficients dans E est une famille d'éléments de E indexée par le produit cartésien I \(\times\) J, c'est-à-dire une application A de I \(\times\) J dans E. Son type (I,J) fait partie de la spécification de la matrice, mais pas l'ensemble E.

Le plus souvent, les ensembles I et J sont finis et sont respectivement les ensembles de nombres entiers {1, …, m} et {1, …, n}. Dans ce cas, on dit que la matrice a m lignes et n colonnes, ou qu'elle est de taille (m,n).
En notant a\(_{i,j}\) l'image d'un couple (\({i,j}\)) par l'application A, la matrice peut alors être notée :

\({(a}_{i,j})_{1\leq i\leq m,1\leq j \leq n}\overset{\underset{\mathrm{def}}{}}{=}
\begin{pmatrix}
a_{1,1}&a_{1,2} &\cdots &a_{1,n}\\
a_{2,1}&a_{2,2} &\cdots &a_{2,n}\\
\vdots &\vdots &\ddots &\vdots \\
a_{m,1}&a_{m,2} &\cdots &a_{m,n}\\
\end{pmatrix}\)

 

Remarque :

Ne pas confondre la matrice (3,4) à coefficients dans E qui a un ordre sur les lignes et sur les colonnes :

\({(a}_{i,j})_{1\leq i\leq 3,1\leq j \leq 4}\overset{\underset{\mathrm{def}}{}}{=}
\begin{pmatrix}
a_{1,1}&a_{1,2} &a_{1,3} &a_{1,4} \\
a_{2,1}&a_{2,2} &a_{2,3} &a_{2,4} \\
a_{3,1}&a_{3,2} &a_{3,3} &a_{3,4} \\
\end{pmatrix}\)

avec une partie du produit cartésien sur E\(^{4}\) qui n'a qu'un ordre sur les « colonnes » qui peut être représenté par un tableau :

{(\({a}_{1,1}, {a}_{1,2}, {a}_{1,3}, {a}_{1,4}\)), (\({a}_{2,1}, {a}_{2,2}, {a}_{2,3}, {a}_{2,4}\)), (\({a}_{3,1}, {a}_{3,2}, {a}_{3,3}, {a}_{3,4}\))}

	\({a}_{1,1}\)	\({a}_{1,2}\)	\({a}_{1,3}\)	\({a}_{1,4}\)
\(\overset{\underset{\mathrm{def}}{}}{=}\)	\({a}_{2,1}\)	\({a}_{2,2}\)	\({a}_{2,3}\)	\({a}_{2,4}\)
	\({a}_{3,1}\)	\({a}_{3,2}\)	\({a}_{3,3}\)	\({a}_{3,4}\)

 

 ni encore avec ce sous-ensemble de parties de E qui ne possède aucun ordre :

{{\({a}_{1,1}, {a}_{1,2}, {a}_{1,3}, {a}_{1,4}\)}, {\({a}_{2,1}, {a}_{2,2}, {a}_{2,3}, {a}_{2,4}\)}, {\({a}_{3,1}, {a}_{3,2}, {a}_{3,3}, {a}_{3,4}\)}}

 

Il n'existe pas réellement de distinction entre un n-uplet du produit cartésien sur E\(^{n}\) et une matrice de dimension (1,n) sur E. Uniquement, l'utilisation permettra de les différencier ainsi que l'absence de virgule de séparation dans la notation matricielle.

 

	Notre approche de l'écriture en ligne, au moins pour la grande majorité des langues utilisées, plutôt qu'en colonne (le chinois mandarin, le japonais et le coréen) a privilégié l'utilisation de l'ordre sur les colonnes dans les tableaux plutôt que celui sur les lignes. Mais, cela n'a rien de nécessaire.
	Lorsque nous travaillons avec un tableau de caractéristiques, il faut bien se demander s'il existe un ordre sur les lignes ou bien sur les colonnes :
	Représentation d'un tableau	Si ordre sur les colonnes	Si pas d'ordre sur les colonnes
	Si ordre sur les lignes	Représentation d'une matrice	Représentation d'un produit cartésien
	Si pas d'ordre sur les lignes	Représentation d'un produit cartésien	Représentation de parties d'ensemble
	Assurément, ce qui a été montré pour un tableau à deux dimensions peut être généralisé à de plus grandes dimensions.

 

L'espace topologique : espace de gestion de projet

 

Les caractéristiques collectées dans l'ensemble projet P doivent désormais être regroupées en sous-ensembles cohérents afin d'assurer leur pertinence pour le projet.

Puis, il faudra s'appuyer sur ces sous-ensembles soigneusement sélectionnés pour gérer le projet.

 

La gestion de projet consiste à définir la manière d'organiser les caractéristiques du projet en différentes parties, de créer des relations entre ces parties et de les regrouper entre elles, afin de créer un espace projet propice à la conduite (visant à atteindre un objectif) et au pilotage (visant à atteindre un objectif dans les meilleures conditions) du projet.

 

Topologie

Une structure topologique (ou plus brièvement une topologie) sur un ensemble E est une structure constituée par la donnée d’une partie O de P(E) qui possède les propriétés suivantes :
(a) La réunion de toute famille d'éléments de O est un élément de O.
(b) L'intersection de toute famille finie d'éléments de O est un élément de O.

• • Par définition O \(\in\) P(P(E))
  • Les éléments de O sont appelés les ouverts, ou les parties ouvertes de E.
  • On appelle topologie grossière sur E : O={\(\Phi\), E}.
  • On appelle topologie discrète sur E : O=P(E)
  • Le couple (E,O) s'appelle espace topologique, E est un ensemble et O une topologie sur E.
  • Il est courant d'appeler les éléments de E des points de l'espace topologique.
  • Un point x d'un espace topologique E est dit isolé si le singleton {x} est un ouvert.

Exemple : un ensemble E de 2 éléments {a, b} peut être muni de quatre topologies différentes:

• • O_g = {\(\Phi\), E}, la topologie grossière,
  • O₁ = {\(\Phi\), {a}, E}
  • O₂ = {\(\Phi\), {b}, E}
  • O_d = {\(\Phi\), {a}, {b}, E}, la topologie discrète.

Notes :

• • Bourbaki sur la définition (a) explique que, comme conséquence des axiomes, dans tout espace topologique (E,O), le tout E et la partie vide \(\Phi\) sont des ouverts : pour Bourbaki (bon barbier selon Ockham), la réunion de la famille vide d'éléments de O est la partie vide \(\bigcup_{i∈\Phi}\)O\(_{i}\)=\(\Phi\), une intersection vide de parties est la partie pleine \(\bigcap_{i∈\Phi}\)O\(_{i}\)= E, il n'est pas utile d'ajouter un autre axiome. Cela se justifie pleinement du point de vue catégorique, mais guère au niveau pédagogique, et bien d’autres définitions préfèrent être claires et pécher par redondance en ajoutant aux axiomes (a) et (b) l’axiome (c) suivant selon lequel E et \(\Phi\) sont des ouverts.
  • Dans l'axiome (b), on peut remplacer ”intersection finie” par ”intersection de deux éléments”, l'équivalence découlant par une récurrence immédiate utilisant l’égalité (O₁ ∩ . . . ∩ O_n) = (O₁ ∩ . . . ∩ O_n−1) ∩ O_n 

 

Lorsqu'il s'agit de faire des regroupements pertinents, pour le projet, de caractéristiques de l'ensemble projet P, la réunion de tous ces regroupements pertinents doit également être considérée comme un regroupement pertinent. De plus, leur intersection doit aussi être considérée comme un regroupement pertinent. L'espace projet (P, O\(\subset\)P(P)) avec O ensemble de tous les regroupements pertinents pour le projet, correspond à un espace topologique dont les ouverts sont les regroupements pertinents de caractéristiques de projet. La méthode JET s'intègre dans ce cadre.

 

Les bases : les dimensions projet

 

Maintenant que nous avons un cadre de travail, l'espace topologique projet (P,O), voyons comment le construire.

Regardons ce qu'une base de topologie peut nous apporter.

 

Base d'une topologie

Soit (E,O) un espace topologique.

• • On dit qu'une partie B de O est une base de O si tout ouvert de O est une réunion d'une famille d'ouverts de B.
  • Un ouvert d'une base B de O s'appelle un ouvert élémentaire de E.

Ainsi, si B est une base de l'espace topologique (E,O), tout ouvert O de E s'écrit :

O = \(\bigcup_{j\in J}{\omega}_{j}\)

Où chaque \({\omega}_{j}\) est un ouvert élémentaire, c'est-à-dire un élément de B.

Le théorème suivant est particulièrement intéressant :

Soient E un ensemble non vide, B une famille non vide de parties non vides de E. Alors B est une base d'une topologie sur E si et seulement si toute intersection finie non vide d'éléments de B est une réunion d'éléments de B.

Une famille non vide de parties non vides de E est donc un moyen très pratique pour construire une topologie sur un ensemble E avec « un minimum de moyens ».

Exemples extrêmes :

Dans une topologie discrète sur E : O=P(E), l'ensemble des singletons est une base de topologie.
Dans une topologie grossière sur E : O={\(\Phi\), E}, l'ensemble {E} réduit à la partie E est une base de topologie.

 

Un des moyens de construire l'espace projet est à partir d'un ensemble D de regroupements pertinents de caractéristiques de l'ensemble projet P, que nous considérons comme fondamentaux (basiques) pour le projet, pour peu que nous respections la contrainte suivante : toute intersection finie non vide d'éléments de cet ensemble D est une réunion d'éléments de cet ensemble. J'appelle D l'ensemble des dimensions de l'espace projet, base de l'espace projet ; et chaque élément de D(ouvert élémentaire de la topologie) une dimension projet. Le dimensionnement de ces regroupements est essentiel, la méthode JET intègre cette contrainte.

 

Les suites : les itinéraires et objectifs projet

 

Atteindre les objectifs du projet constitue l'action essentielle à réaliser.

Pour mieux comprendre cela, examinons d'abord d'autres notions telles que la comparaison de la finesse des topologies, la notion de voisinage, d'intérieur, d'adhérence, de frontière et de séparation. Ensuite, nous examinerons comment l'utilisation des suites topologiques peut nous permettre de représenter l'accomplissement des objectifs du projet.

 

Finesse relative de topologies

Soient E un ensemble, O et O' deux topologies sur E. La topologie O est dite plus fine que  O' lorsque  O' \(\subset\)  O et moins fine si O \(\subset\) O' .

La topologie grossière sur E : O={\(\Phi\), E} est la moins fine des topologies sur E.
La topologie discrète sur E : O=P(E) est la plus fine des topologies sur E.

 

Voisinage

Soit (E,O) un espace topologique non vide et x \(\in\) E un point de cet espace. On appelle voisinage de x toute partie de E contenant un ouvert contenant x.
Ou plus généralement, soit A une partie de E. On appelle voisinage de A toute partie de E contenant un ouvert contenant A.

Si x est un point de (E,O), on note V(x) l'ensemble des voisinages de x. \(\forall\) x\(\in\) E, \(\forall\) V \(\in\) V(x), x \(\in\) V

 

x est un point intérieur à A si A est un voisinage de x.
L'intérieur Å de A est l'ensemble de tous les points intérieurs de A.

 

x est un point adhérent à A si tout voisinage de x rencontre A (c.-à-d. : voisinage non disjoint de A \(\Leftrightarrow\) intersection non vide).
L'adhérence \(\bar{A}\) de A est l'ensemble des points adhérents à A.

 

x est un point frontière de A s'il est simultanément adhérent à A et à son complémentaire sur E.
La frontière de A est l'ensemble des points frontière de A.

 

Espace topologique séparé

Un espace topologique (E,O) est séparé s'il vérifie la propriété suivante : pour tout couple de points distincts a et b de E, il existe un voisinage V_a de a et un voisinage V_b de b de E tels que V_a\(\cap\)V_b = \(\Phi\).

 

Dans l'ensemble projet P, nous trouvons simultanément des caractéristiques propres au projet et des caractéristiques propres à son environnement. La notion d'intérieur nous permet de conceptualiser la partie propre au projet, sa frontière, l'interface avec son environnement ou entre un projet et des sous-projets.

 

Suite dans un espace topologique

Une suite d'un espace topologique (E,O) est une application x : \(\mathbb{N}\to\) E.

On note x\(_{n}\) l'image de n par x et (x\(_{n}\))\(_{n∈ \mathbb{N}}\) la suite elle-même.

 

Convergence d'une suite

 Soit (x\(_{n}\))\(_{n∈ \mathbb{N}}\) une suite d'un espace topologique (E,O). On dit que cette suite converge vers a \(\in\) E si

 \(\forall\) V \(\in\) V(a), \(\exists\) N \(\in\) \(\mathbb{N}\) tel que \(\forall\) n \(\geq\) N, x\(_{n}\) \(\in\) V(a)

Si l'espace topologique est séparé, a est unique et la convergence est notée :

\(\displaystyle \lim_{n \to \propto} x_{n}\) = a

 

Une suite, convergente, dans un espace projet peut être vue comme un itinéraire, une progression, aboutissant à un point caractéristique (fin du projet, objectif atteint…). La convergence de suites projet = l'atteinte des objectifs projet. En topologie, la limite d'une suite convergente n'est pas forcément unique, sauf si la topologie est séparée. Par conséquent, pour s'assurer que nos axes de signification du projet convergent bien chacun vers l'objectif attendu, il serait bon de ne travailler qu'avec une topologie séparée. En topologie, la convergence ou non d'une suite ne dépend pas uniquement de la définition de la suite elle-même, mais également de la topologie, donc des ouverts élémentaires choisis. Belle preuve que la structuration d'un projet, avec des dimensions projet bien choisies pour définir l'espace projet, permet de trouver la convergence des suites correspondant aux axes de signification du projet, en d'autres termes d'atteindre les objectifs projet ! Une autre structuration (gestion de projet) de l'espace projet ne permet peut-être pas d'atteindre les objectifs projet. Preuve, s'il en était besoin, que la façon de gérer son projet conditionne sa réussite ! Plus une topologie est fine (avec ajout d'ouverts dans la topologie existante), moins il y aura de suites convergentes (théorème de topologie générale). Appliqué à notre projet, plus la gestion est lourde, plus il est difficile d'atteindre les objectifs. Tout directeur de projet pourrait l'attester !

 

Sous-projets et produit de projets

 

Sous-projets et programme

Un projet peut être découpé en plusieurs sous-projets.

Ce qui correspond à considérer le projet P comme une réunion de sous-projets P\(_{i}\),

P = \(\displaystyle \bigcup_{i}\)P\(_{i}\), chaque sous-projet P\(_{i}\) étant un projet sur un sous-ensemble projet P\(_{i}\) \(\subset\) P.

Faut-il pour autant gérer de la même façon un sous-projet que le projet lui-même ?

La réponse formelle est non, mais elle dépend aussi de la complexité du projet. Car, il est au moins nécessaire de différencier les moyens de gestion, vous ne pouvez pas utiliser la même topologie pour P et pour les P\(_{i}\), vous devez travailler sur des espaces projet différents car au minimum la topologie sur P doit être restreinte à P\(_{i}\). Une adaptation de gestion est nécessaire.

L'espace projet de P =  (P, O\(\subset\)P(P))

L'espace projet de P\(_{i}\),=  ( P\(_{i}\), O\(_{i}\) \(\subset\)P( P\(_{i}\))) avec P\(_{i}\) \(\subset\) P et

• • O\(_{i}\) peut être une toute autre topologie que celle sur P, choix correspondant à une distinction forte des moyens de gestion d'avec ceux du projet P, dans le cas par exemple où le sous-projet P\(_{i}\) est confié à une autre entreprise ou que le sous-projet est simple, ou
  • O\(_{i}\) est la topologie sur P restreinte à P\(_{i}\), choix correspondant à une distinction faible des moyens de gestion d'avec ceux du projet P, si par exemple le sous-projet P\(_{i}\) est interne à la même entreprise en charge du projet P.

 

Et, pour la gestion de programme ?

De même, la gestion d'un programme P, défini comme une réunion de projets P\(_{i}\) procède de la même logique. Une adaptation de gestion est nécessaire.

 

Produit de projets

Lorsque le projet est très complexe ou bien que les axes de signification sont nombreux et de nature très différente (coût, durée, performances, impact social ou politique, notoriété…), il semble évident que les moyens à mettre en œuvre pour atteindre les différents objectifs attachés à chaque axe de signification du projet doivent aussi être différents et nécessiter des moyens de gestion différents.

Je vous demande de bien faire attention à ce point car nous allons monter en abstraction avec l'introduction d'un produit d'espaces topologiques.

Là, nous ne sommes pas dans le cas d'un sous-projet. En effet, nous sommes toujours avec le même ensemble projet P pour le même projet P. Regardons comment un produit d'espace topologique pourrait nous aider.

 

Produit d'espace topologique

Considérons une famille (E\(_{i }\),O\(_{i }\))\(_{i \in I}\) d'espaces topologiques et posons :

E =\(\displaystyle \prod_{i\in I}E_{i}\)

L'ensemble E est donc le produit des ensembles (E\(_{i }\))\(_{i \in I}\). On suppose que \({I}\) n'est pas vide, et qu'il peut être fini ou infini.

On appelle topologie produit sur E la topologie dont une base B est l'ensemble des parties

\(\omega\) =\(\displaystyle \prod_{i\in I}O_{i}\)

où \(O_{i}\) \(\in\)  O\(_{i}\), et où l'ensemble des \(O_{i}\) différents de \(E_{i}\) est fini. 

Naturellement, si \({I}\) est fini, la topologie produit sur E est simplement engendrée par la base dont les ouverts \(\omega\) sont les produits d'ouverts des \(\omega_{i}\) = \(O_{i}\).

 

Comme avec les projets, nous ne sommes qu'en espace fini. Nous voyons qu'il est possible avec la même méthode, c'est-à-dire grâce aux dimensions (ouverts élémentaires), de structurer un espace projet comme produit d'espaces projet adaptés aux différents objectifs à atteindre ou à des niveaux de complexité différents.

 

 

Décider de créer des sous-projets au sein d'un projet nécessite une adaptation plus ou moins importante des moyens de gestion. Tout en gardant une structuration reposant sur des dimensions projet qui doivent être adaptées au périmètre des sous-projets différents P\(_{i}\) \(\subset\) P . Décider d'encadrer en programme un ensemble de projets existants est équivalent à considérer le programme comme un projet ayant en sous-projets les projets constituant ce programme. Tout en gardant une structuration reposant sur des dimensions programme, mais avec une gestion très allégée pour être en mesure de conserver les espaces projets existants. Lorsque la complexité d'un projet est importante, soit par sa nature ou par la diversité de ses objectifs, il est possible de travailler sur plusieurs espaces projet structurés en produit sur le même ensemble projet P.

 

Conclusion

 

Le pilotage d'un projet, en particulier de grands projets complexes, demande simultanément une grande flexibilité et une grande généralité dans les représentations qu'un directeur de projet doit avoir en tête. La tâche a consisté à chercher non seulement les représentations liées à un projet, mais également celles liées à la gestion de projet.

Chaque projet complexe que j'avais réalisé, en recourant à ce que je désignais déjà comme des dimensions de projet, apparaissait comme une tâche particulièrement ardue à modéliser, eu égard au degré élevé de généralité que ce modèle devait nécessairement englober.

J'ai cherché longtemps, me suis égaré sur beaucoup de chemins en algèbre et j'ai insisté longtemps sans résultat avec des espaces vectoriels. Puis, révélation avec la topologie générale, où toutes les idées que j'avais pouvaient trouver un support. L'harmonisation de deux concepts représente un véritable plaisir, comme si notre corps, et plus particulièrement notre esprit, s'immergeait dans un océan de lumière. Voici ce que j'ai ressenti lorsque m'est apparue la possibilité de modéliser la représentation de projet que j'avais en tête avec la théorie de la topologie générale.

L'émergence de la solution à mon problème est arrivée lorsque, lassé de modéliser des structures de données, je me suis posé la question des grains élémentaires nécessaires à un projet : les caractéristiques primaires d'un projet. Je les ai naturellement mis dans des ensembles et un nouveau chemin est apparu. Ce document reflète une grande partie du modèle que j'ai élaboré en collant au plus près à la topologie générale.

Les contraintes de convergence des suites dans un espace projet mettent en évidence des ressentis que tout directeur de projet a déjà expérimentés. C'est très drôle et cela me fait penser que le modèle topologique convient bien pour représenter la gestion d'un projet : le méta-projet. Les principaux résultats sont résumés ci-dessous.

 

Une caractéristique est une information primaire, qui concerne le projet et son environnement, qu'elle soit descriptive ou numérique. Un ensemble fini de caractéristiques pertinentes pour le projet est un ensemble projet P. L'ensemble des parties de P est noté P(P), aussi appelé ensemble puissance de P. Il contient par définition l'UN et le TOUT de même que le RIEN. L'espace projet (P, O\(\subset\)P(P)) avec O ensemble de tous les regroupements pertinents pour le projet, correspond à un espace topologique dont les ouverts sont les regroupements pertinents de caractéristiques de projet. La gestion de projet consiste à définir la manière d'organiser les caractéristiques du projet en différentes parties, de créer des relations entre ces parties et de les regrouper entre elles, afin de créer un espace projet propice à la conduite (visant à atteindre un objectif) et au pilotage (visant à atteindre un objectif dans les meilleures conditions) du projet. Un des moyens de construire l'espace projet est à partir d'un ensemble D de regroupements pertinents de caractéristiques de l'ensemble projet P,  les dimensions projet. La notion d'intérieur nous permet de conceptualiser la partie propre au projet, sa frontière, l'interface avec son environnement ou entre un projet et des sous-projets. Le produit cartésien suffit pour avoir un outil pour créer des listes ordonnées de caractéristiques projet, donc de la priorisation de n'importe quel jeu de caractéristiques. Concrètement, nous analyserons les situations de projet avec des graphes, bien choisis, appelés représentations projet. La convergence de suites projet permet de modéliser l'atteinte des objectifs projet. Les valeurs à chaque pas des suites correspondent aux points de situation du projet. Décider de créer des sous-projets au sein d'un projet nécessite une adaptation plus ou moins importante des moyens de gestion en fonction du lien de gestion entre le projet et les sous-projets. Décider d'encadrer en programme un ensemble de projets est équivalent à considérer le programme comme un projet ayant en sous-projets les projets constituant ce programme avec une gestion très allégée pour être en mesure de conserver les espaces projets existants. Lorsque la complexité d'un projet est importante, soit par sa nature ou par la diversité de ses objectifs, il est possible de travailler sur plusieurs espaces projet structurés en produit sur le même ensemble projet P. Il convient d'adopter une approche appropriée dans la définition de l'ensemble projet P, des dimensions de projet D ainsi que d'un ou des espaces projet (P, O) : toute intersection finie non vide de dimensions est une réunion de dimensions afin de construire l'espace projet, ni trop, ni trop peu de dimensions pour avoir la finesse adéquate et la convergence des suites, pour construire une topologie séparée afin d'avoir l'unicité des limites des suites. Nous avons maintenant les fondements théoriques pour mettre en œuvre la méthode JET.