# “Insee 2004” et le pilotage par les délais

Pascal Rivière

► To cite this version:

Pascal Rivière. “Insee 2004” et le pilotage par les délais. Courrier des Statistiques, 2003, 105-106, pp.35-38. hal-05515586

HAL Id: hal-05515586

https://insee.hal.science/hal-05515586v1

Submitted on 17 Feb 2026

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons CC BY 4.0 - Attribution - International License
# « Insee 2004 » et le pilotage par les délais

À la fin de l'année 2001, l'Insee s'est engagé dans un ambitieux programme baptisé Insee 2004, englobant un ensemble de travaux jugés prioritaires, et caractérisés le plus souvent par des délais affichés sur lesquels l'institut s'engageait. Du strict point de vue des projets informatiques, sont concernés le recensement rénové de la population (RRP), Sirene 3, l'indice des prix à la consommation rénové (IPCR), l'opération CLAP (connaissance locale de l'appareil productif), enfin l'objectif OCRE (offre cohérente pour les régions). Il n'est pas rare que l'Insee se lance ainsi dans des projets ambitieux et innovants. Avec Insee 2004, la nouveauté vient du fait que plusieurs projets ambitieux sont lancés simultanément, avec de « vrais » délais sur lesquels on ne dispose pas de marge de manœuvre.

La variable *délai* apparaissant désormais comme une contrainte très forte, et l'opération Insee 2004 apportant à la conduite des projets une dimension nouvelle, transversale et interdirectionnelle, le « pilotage par les délais » s'est imposé petit à petit aux équipes de projet, et a provoqué un changement d'habitudes et d'attitudes tout au long de l'année 2002. Nous nous proposons ici de tirer quelques enseignements de ces premières expériences.

## Tenir les délais

Tentons d'abord de poser le problème. Un projet se caractérise par des objectifs, des ressources (moyens humains, financiers) pour les atteindre, et des délais à respecter. Bien évidemment, tout cela n'est pas gravé dans le marbre, car un projet n'a rien de linéaire et de déterministe. La plupart du temps, les objectifs évoluent, parfois de façon insensible mais régulière, parfois de

façon ponctuelle mais forte. D'autre part, les ressources peuvent être ajustées, et les délais ne constituent pas toujours une contrainte incontournable.

Avec la fixation d'une date butoir, comme cela a été le cas pour chacun des projets Insee 2004, l'un des degrés de liberté disparaît : le dérapage n'est plus permis, et si des difficultés apparaissent, il va falloir s'organiser pour « tenir » cette date. Les deux principaux leviers sur lesquels on pourra alors jouer sont d'abord le périmètre du projet, ensuite le volume des moyens mis en œuvre. En dernière extrémité, il faudra accélérer la mise en production de l'application en question, mais avec tous les risques qu'emporte une telle anticipation : nous y reviendrons.

Si l'on adopte un raisonnement économique, il est clair qu'il existe un quatrième instrument d'action : la productivité. À moyens constants, quantité de travail constante, délai fixé, la productivité est en effet une

variable d'ajustement toute désignée. Mais autant on peut décider de mobiliser plus de moyens, de réduire le nombre de fonctionnalités offertes par une application, d'abréger les phases de tests ou de « recette » (réception/vérification), autant il paraît difficile de décréter une augmentation de la productivité (même si l'on peut « mettre les bouchées doubles » pour tenir dans les délais). De ce point de vue, la productivité n'est pas, au sens strict, un instrument de pilotage. Cela n'empêche pas de chercher à l'augmenter, mais cela se passera sur une échelle de temps plus longue (organisation plus adaptée des développements, utilisation de composants métier, appel à des spécialistes bien identifiés pour tel ou tel aspect pointu...).

Notons enfin que le paramètre « délai », sorti par la porte, revient rapidement par la fenêtre. En effet, dans la pratique, on fixe certes une date butoir de mise en production, mais il s'agit souvent de la mise en production d'une partie d'une application, ou d'une application amenée à évoluer encore par la suite. On entre ainsi dans une logique de livraisons échelonnées dans le temps<fnref n="1" />, la contrainte forte pesant sur la ou les premières livraisons, correspondant aux fonctionnalités prioritaires. Cela étant, le problème demeure : il faut tenir une date butoir. Dans ce qui suit, nous allons étudier de plus près ce qui caractérise les trois instruments d'action évoqués plus haut, et leurs avantages et inconvénients dans la pratique.

<figure><img src="image_2.png" /></figure>

www.buriller.uranie.com

<caption>Ce sablier de quart est la réplique exacte d'un original qui, au XIXe siècle, régissait le temps à bord d'un vaisseau amiral.</caption>

<footnote n="1">1. On rejoint ici l'idée d'allotissement, qui consiste à découper un projet en lots successifs (par exemple, pour une enquête, un lot « tirage d'échantillon », un lot « gestion de la collecte », un lot « saisie », un lot « contrôles », etc.) avec échelonnement des livraisons afférentes.</footnote>
Réduire le périmètre
du projet

C'est la première idée qui vient à l'esprit : pour tenir dans les temps, limitons-nous au strict nécessaire.

Dans les projets Insee 2004, en parti-
culier les plus contraints en temps, la
réduction du périmètre a été appli-
quée de façon quasi systématique.
Et que découvre-t-on en pratique ?
Une réalité importante et non évi-
dente a priori : ce n'est pas parce
que l'on fait moins de choses, en
moins de temps, que le résultat est
nécessairement moins bon. En effet,
la recherche d'un périmètre minimal
conduit à s'interroger sur les vrais
objectifs du projet, sur ce qui est
important et ce qui ne l'est pas. En
 faisant cela, les acteurs du projet
sont obligés de le clarifier, de le
rendre lisible, compréhensible ; et
inévitablement, ils évacuent les
fonctionnalités supplémentaires
mineures, en se recentrant sur l'es-
sentiel. Le projet acquiert les qualités
de sobriété parfois oubliées en cours
de route, et l'effet est donc souvent
positif. Ainsi épurée, l'application
sera plus évolutive, plus facile à
maintenir.

Naturellement, une fois le périmètre
arrêté, l'équipe de projet s'efforcera à
un suivi le plus rationnel et le plus
rigoureux possible des charges et du
planning, de manière à savoir à tout
moment si l'on « tient » ou pas dans
les temps et si des moyens supplé-
mentaires seront ou non nécessaires.

Augmenter les moyens
en interne : pas si simple...

Le tableau de bord semestriel, géré
par le département de la program-
mation et de la gestion, permet de
fixer les moyens alloués et de plani-
fier, mais, du point de vue des pro-
jets, tout cela ne concerne que la
partie informatique. D'autre part, il ne
s'agit que de moyens « sur le

Une démarche à généraliser

La chasse au superflu participe d'un principe de bonne gestion, applicable à n'importe quelle opération autre que les projets informatiques classiques (enquêtes, études...). Bien sûr, l'approche nécessite alors une analyse très détaillée de l'ensemble des travaux en question, un véritable descriptif du processus de production, afin de déterminer sur quoi il est possible de faire des économies. Et là, pour chacune des tâches, il faut poser la question iconoclaste : si on la supprime, qu'est-ce qui se passe, quelle est la conséquence ? Et, souvent, on s'aperçoit que nombre d'entre elles sont en réalité inutiles : simplement, elles sont faites par habitude, par inertie de l'organisation, « parce qu'on a toujours fait comme ça ». Cela a notamment été le cas lors de la mise en œuvre, en 1993, d'une démarche TQM (Total Quality Management) à l'institut statistique suédois<fnref n="1" />. Naturellement, ces actions « qualité totale », qui demandent un minimum d'intrusion dans les travaux de chacun (pour comprendre comment ça marche), seront d'autant plus efficaces qu'elle rencontreront un maximum d'adhésion.

papier », le recrutement s'effectuant
via les campagnes de mutations, en
règle générale à périodicité annuelle.
Toutefois, il existe également des
campagnes de mutations trimes-
trielles, internes aux centres natio-
naux informatiques. C'est pourquoi il
est moins difficile d'obtenir des
moyens du côté informatique que du
côté maîtrise d'ouvrage, surtout en
cours d'année. Une autre raison de
cette moindre difficulté tient au fait
que le travail de l'informaticien se
caractérise en bonne partie par les
outils techniques utilisés, et si ceux-
ci sont similaires d'un projet à l'autre,
cela facilitera le changement de
poste.

Cela dit, beaucoup d'informaticiens
sont déjà impliqués sur des projets
ou sur la maintenance d'applications,
et de ce fait n'ont pas de temps à
consacrer à un autre projet, ou alors
seulement de façon ponctuelle. De
plus les ressources ne sont pas si
facilement interchangeables, en rais-
son notamment de la technicité
nécessaire à certaines applications
(maîtrise des techniques de pro-
grammation en Java, ou connais-
sance pointue du système de gestion
de bases de données Oracle). Par
conséquent, les possibilités de réal-

location de moyens peuvent se révé-
ler plus réduites qu'il n'y paraît<fnref n="2" />.

Dans les faits, on observe donc un
manque de souplesse dans la réallo-
cation de moyens humains, notam-
ment dans le cas des personnels tra-
vaillant pour la maîtrise d'ouvrage : il
est très difficile, voire quasi impos-
sible, de recruter en cours d'année
un nouveau statisticien dans une
équipe de projet statistique. En
d'autres termes, en dehors de la
campagne de mutations (ce qui
oblige à anticiper de plusieurs mois),
point de salut. En même temps, l'im-
pact sur les délais du manque de
statisticiens « spécifieurs » est
énorme : si l'on a un seul statisticien
en face d'une équipe d'informati-
ciens, et s'il n'a pas le temps d'écrire
des spécifications pour tout le
monde, la quantité de moyens infor-
matiques mobilisés devient de fait
inutile. Il y a donc une difficulté géné-
rale de synchronisation des moyens.
D'autre part, le « rendement » des
moyens dépend beaucoup du stade
du projet auquel ils sont mobilisés :
ainsi, désigner très tôt un CPOI (chef
de projet organisation informatique)
alors que le contour du projet n'est
pas vraiment dessiné se révèle sou-
vent inefficace.

<footnote n="2">2. Il a ainsi été nécessaire, pour le bouclage du projet IPCR, de faire appel à des informaticiens travaillant sur le RRP.</footnote>

<footnote n="1">1. Concernant l'approche TQM et l'expérience suédoise, cf. en particulier un article intitulé « Qualité et statistique », publié dans le numéro 90 (juin 1999) de cette même revue.</footnote>
## Le recours à des prestataires externes

Une autre possibilité, s'il faut augmenter les ressources, est bien sûr de faire appel à des prestataires externes, que ce soit en assistance à maîtrise d'ouvrage ou en assistance à maîtrise d'œuvre. Dans le premier cas, cela requiert de toute façon une disponibilité importante de la maîtrise d'ouvrage. Dans le second, cela peut permettre de débloquer certaines situations dans des domaines très techniques (liés aux nouvelles technologies) qui ne sont pas encore totalement maîtrisés. L'assistance maîtrise d'œuvre peut également être précieuse en tout début d'opération, afin d'aider à mettre l'équipe de projet sur de bons rails, notamment lorsqu'il faut travailler avec de nouveaux outils, une nouvelle architecture.

Mais là aussi on observe un relatif manque de souplesse, dû aux procédures d'achat public. Si le montant est tel qu'il faut passer un marché, le temps de préparation des cahiers des charges et la multiplicité des points de contrôle entraînent inévitablement des délais de plusieurs mois, en général 6 mois minimum, ce qui rend totalement impossible une réactivité immédiate. Au-dessous du seuil de 90 000 euros, on peut envisager de passer par bons de commande, mais il demeure nécessaire d'effectuer une mise en concurrence de plusieurs sociétés, en général au moins trois. D'autre part, on ne peut passer systématiquement par le même prestataire, même si celui-ci donne entière satisfaction, toujours en raison de ces problèmes de mise en concurrence. On peut tout de même dire qu'avec une bonne organisation, et si les montants sont peu élevés, il est possible de faire appel rapidement à un prestataire.

## La délicate question de la qualité

La qualité d'un produit ou d'un service, si l'on s'en tient à cette définition générale, réside dans son aptitude à satisfaire les besoins exprimés ou implicites des utilisateurs. Pour

## Informaticien : un métier aux multiples facettes

Dans la pratique, du moins si l'on en croit la littérature, l'écriture de programmes ne représente que de 15 à 20 % du temps de travail des informaticiens. Les plus de 80 % restants, c'est pour la conception, la modélisation, la planification et l'estimation des charges, la détermination des infrastructures nécessaires (pour le développement, les tests et la production), les diverses documentations, les formations, l'assistance, la rédaction de cahiers des charges, l'aide à la définition du besoin avec le demandeur, les tests (tests fonctionnels, tests de charge), la recette, le déploiement, la mise en production... avec les innombrables réunions et déplacements que suppose cette omniprésence à tous les stades du projet.

une application informatique, il s'agit d'assurer que celle-ci offre bien les fonctionnalités souhaitées, et que l'utilisation de l'outil se fait dans de bonnes conditions. En ces matières, la phase cruciale est celle de l'après-développement. Car contrairement à ce que l'on pourrait penser, un projet ne s'achève pas une fois les développements terminés. Il reste à procéder aux tests, à la recette, au déploiement, à la documentation et aux formations. De fait, l'expérience montre qu'il faut compter un délai de 3 à 6 mois environ entre achèvement des développements et passage effectif en production.

Or, si la qualité n'est pas un paramètre sur lequel on joue rationnellement, consciemment, elle se trouve être, ex post, une variable d'ajustement. En effet, si pour respecter la date butoir on doit jouer sur le délai de mise en production, par exemple en rognant sur les tests, ou sur l'effort de documentation, on joue en fait sur la qualité de l'application, qui sera moins fiable, moins solide, prénsentera des comportements que l'on ne saura pas bien expliquer. Et presque inévitablement apparaîtront des problèmes, que l'on aurait dû normalement déceler en amont mais qu'il faudra gérer en pleine production, avec toute la gêne (et aussi le surcoût) que cela occasionnera.

Ce que l'on constate donc, en pratique, c'est la grande difficulté de la préparation de la mise en production

d'une application, et, par là même, la nécessité de mieux anticiper ce passage en production, d'autant plus impérieuse dans un environnement rendu plus complexe par l'invasion des nouvelles technologies<fnref n="3" />.

## Un nouvel état d'esprit

Le pilotage par les délais est désormais effectif pour plusieurs gros projets de l'Institut. Cette façon de procéder soumet parfois les équipes de projet (informatiques et statistiques) à rude épreuve, notamment vers la fin, lorsque l'inattendu émerge. Il est encore trop tôt pour en tirer les leçons, mais l'on peut dire d'ores et déjà qu'il s'agit d'une excellente expérience pour l'Insee.

Elle met en évidence notre capacité à faire, à agir collectivement et efficacement de façon intense, mais aussi, parfois, nos limites en termes de souplesse de réaffectation de moyens. Elle révèle aussi la grande difficulté de l'estimation de charges et de la planification : pour bien piloter par les délais, il faut une conscience partagée de ce qui « fait » les délais.

<footnote n="3">3. Variété des techniques à appréhender et à maîtriser, processus de production plus hétérogènes et plus compliqués à tester, problématique de la sécurité... De plus, le manque d'expérience de ces nouvelles architectures rend plus difficile l'estimation des charges, de par la grande quantité de petits problèmes techniques non anticipés qui apparaissent au fur et à mesure, au moment de l'« atterrisage » du projet.</footnote>
Le pilotage par les délais et la mise à
plat qu'il implique permettent aussi
de faire comprendre, a posteriori,
pourquoi les projets sont parfois si
longs à aboutir, l'une des raisons
majeures étant le degré de détail des
fonctionnalités souhaitées, par
absence de limites aux desiderata
des utilisateurs ; piloter par les délais
oblige à poser de telles limites, et
oblige les concepteurs à un travail de
clarification qui ne peut être que

bénéfique, à court terme (lisibilité,
maîtrise) et à long terme (mainte-
nance facilitée).

Il s'agit aussi d'un changement d'état
d'esprit. Dans le cadre du projet, on
doit s'attacher à déterminer le vrai
besoin, les vrais délais, les vraies
priorités, les vrais coûts. Au-delà du
projet, tout cela ne peut que nous
amener à un vrai pilotage, plus
pertinent et plus tranché, concernant

l'organisation de nos travaux de
production statistique et, plus
généralement, le fonctionnement
d'ensemble de notre Institut.

Pascal RIVIÈRE
Insee, direction générale

Pascal Rivière est le chef du
département Applications et projets.