Mis à jour le 24 min de lecture
Sébastien Nobour
Fondateur de DEVEDANOS
Le jeu vidéo Grand Theft Auto VI devait sortir en 2025 ; après deux reports, il est annoncé pour le 19 novembre 2026. Dans le désert saoudien, une ville de 170 kilomètres de long a été annoncée en 2021 ; ses travaux seraient aujourd’hui reportés après 2030. Au Sénégal, une ville nouvelle annoncée à six milliards de dollars doit être remplacée par un projet immobilier. Et en France, au Canada ou au Royaume-Uni, les contrôleurs des comptes publics décrivent le même schéma dans l’informatique.
Ces projets n’ont rien en commun, sauf une chose : une date et un budget annoncés pour un ouvrage qui n’avait encore jamais été réalisé, et qui demandait de la conception, de la recherche et de la construction.
Grand Theft Auto, ou GTA, est une franchise de jeux vidéo du studio Rockstar Games, éditée par Take-Two Interactive. Elle n’est pas nouvelle : depuis 1997, elle compte sept épisodes principaux, et une quinzaine de jeux en ajoutant les extensions et les titres dérivés (Wikipédia). Le 4 décembre 2023, la première bande-annonce du sixième épisode est vue plus de 90 millions de fois sur YouTube en 24 heures, un record selon le Guinness World Records. Elle annonce une sortie en 2025.
Voici chaque date annoncée depuis, et chaque confirmation, telles que l’éditeur et le studio les ont publiées :
| Date de l’annonce | Sortie annoncée | Ce qui a été dit |
|---|---|---|
| 4 décembre 2023 | 2025 | Communiqué de Take-Two |
| 2 mai 2025 | 26 mai 2026 | Premier report, annoncé par Rockstar |
| 7 août et 10 septembre 2025 | 26 mai 2026 | Take-Two reprend la date dans ses résultats trimestriels, puis dans une présentation à ses investisseurs |
| 6 novembre 2025 | 19 novembre 2026 | Second report, le jour des résultats trimestriels de Take-Two |
| Février à octobre 2026 | 19 novembre 2026 | Take-Two reprend la date à chaque publication de ses résultats (février, mai, août), puis la bande-annonce de lancement du 15 octobre la maintient |
Cette date ne concerne pas que les joueurs. Dans ses résultats d’août 2026, Take-Two maintient sa prévision de ventes pour l’exercice en cours, entre 8 et 8,2 milliards de dollars, en invoquant la sortie du 19 novembre.
D’un épisode à l’autre, beaucoup de choses se répètent. Mais GTA VI ouvre une nouvelle ère, une nouvelle génération de la franchise, plus de dix ans après GTA V, sorti le 17 septembre 2013. C’est ce qui en fait un ouvrage nouveau, et non une répétition. Chaque date de ce tableau était une estimation, et chacune a été présentée comme une échéance.
Le 10 janvier 2021, le prince héritier d’Arabie saoudite, Mohammed ben Salmane, annonce The Line, une ville en ligne droite de 170 kilomètres dans NEOM, une zone de développement du nord-ouest du pays (Gulf News). Le 25 juillet 2022, il en dévoile les plans : 200 mètres de large, et 9 millions d’habitants à terme (Khaleej Times).
| Date | Ce qui a été annoncé ou rapporté depuis |
|---|---|
| Avril 2024 | Selon Bloomberg, qui cite des sources anonymes, 2,4 kilomètres seulement seraient achevés d’ici à 2030 (relayé par Dezeen) |
| Janvier 2026 | Selon le Financial Times, The Line serait redessinée en un projet bien plus modeste (relayé par Archinect) |
| 22 mai 2026 | Selon Semafor, qui cite des sources anonymes, les travaux sont reportés au moins après 2030 (Semafor) |
Au 20 octobre 2026, aucune annulation officielle n’a été annoncée : selon le fonds souverain saoudien, des projets de NEOM sont reportés, aucun n’est annulé (AFP, relayée par Macau Business). Des contrats ont pourtant été résiliés, dont celui du creusement de ses tunnels (MEED).
Au Sénégal, Akon City, le projet du chanteur Akon, qui lui a donné son nom, devait s’élever sur 800 hectares à Mbodiène, au sud de Dakar. Annoncé en juin 2018, il était chiffré à six milliards de dollars, avec une première phase prévue pour la fin de 2023 (BBC, relayée par Capital FM). En 2024, seule la structure d’un bâtiment d’accueil est sortie de terre (Ecofin). Le 26 juin 2025, l’aménageur touristique public déclare : « Le projet Akon City n’existe plus. » Un projet immobilier doit le remplacer (Le Soleil).
Le schéma est le même : une vision rendue publique avec ses chiffres, puis des objectifs revus à la baisse, l’un après l’autre.
Non. C’est là qu’on compte le plus d’échecs. Bent Flyvbjerg, professeur à l’université d’Oxford, a étudié 4 677 projets informatiques : le dépassement moyen atteint 80 % du devis (Flyvbjerg et al., 2022). Nous détaillons ces chiffres dans notre article sur les dépassements de budget des projets logiciels. Les projets publics le montrent mieux que les autres, parce que leurs comptes sont publiés.
En France, le ministère de l’Éducation nationale lance en 2007 SIRHEN, un système de gestion de ses ressources humaines prévu pour 60 millions d’euros. Arrêté en juillet 2018, le programme a coûté plus de 400 millions d’euros. La Cour des comptes qualifie l’estimation de départ d’« irréaliste » (rapport public annuel 2020).
Au Canada, le logiciel de paie des fonctionnaires fédéraux, Phénix, est budgété à 155 millions de dollars canadiens (rapport du Sénat du Canada, 2018). Mis en service en 2016, il multiplie les erreurs de paie ; en 2025, les corriger avait coûté plus de 5,1 milliards de dollars (La Presse Canadienne).
Au Royaume-Uni, le programme d’informatisation du système de santé britannique devait notamment doter les hôpitaux d’un dossier médical électronique ; les prestataires ne sont pas parvenus à le déployer entièrement (The Register). Démantelé en 2011, il a vu son coût prévisionnel passer de 6,4 à 9,8 milliards de livres, pour des bénéfices estimés à 3,7 milliards jusqu’en mars 2012, environ la moitié des sommes dépensées à cette date. Richard Bacon, député membre de la commission des comptes publics de la Chambre des communes, y voit « l’un des pires et des plus coûteux fiascos contractuels de l’histoire du secteur public » (National Health Executive).
Vous pensiez que c’étaient des cas isolés ? Détrompez-vous. Cela arrive bien plus souvent que vous ne le pensez, et ces dépassements ont une cause commune.
Un jeu, une ville, un logiciel public : dans chacun de ces projets, la date et le budget reposent sur une estimation, que l’on croit fiable. Elle ne l’est pas.
Ce que l’on refait à l’identique devient prévisible, et d’ailleurs on finit par l’automatiser. Un logiciel, lui, se développe toujours pour la première fois. Sinon, on l’installerait. Chacun de ces projets est une œuvre que personne n’avait réalisée auparavant. En estimer la durée revient à faire une supposition.
La science l’explique. En 1972, le physicien Philip Anderson (prix Nobel de physique, 1977) publie dans la revue Science « Plus, c’est différent ». Sa thèse : à chaque niveau de complexité, de nouvelles propriétés émergent, que l’on ne peut pas prédire en étudiant les parties isolément. La chimie n’est pas de la physique appliquée, ni la biologie de la chimie appliquée. Un ouvrage qui n’a jamais été conçu n’est pas une addition de tâches que l’on chiffrerait une à une : ce n’est pas de la mécanique automobile, et on ne peut pas l’estimer de façon fiable. De leur côté, les psychologues Daniel Kahneman et Amos Tversky ont décrit à la fin des années 1970 ce qu’ils appellent l’« erreur de planification » : même en sachant que des projets semblables ont dépassé leurs prévisions, nous sous-estimons le temps et le coût des nôtres. Le bon sens n’avait d’ailleurs pas attendu la science pour le constater.
Pourquoi continue-t-on, alors ? La pratique vient de l’industrie manufacturière. La vision du monde qui la porte est bien plus ancienne. Elle tient en deux idées : un problème se résout en le découpant en parties, et qui connaît assez bien le présent peut prévoir l’avenir.
En 1637, dans le Discours de la méthode, le philosophe René Descartes se donne pour deuxième règle « de diviser chacune des difficultés que j’examinerois, en autant de parcelles qu’il se pourroit, et qu’il seroit requis pour les mieux résoudre » (Wikisource). Le mathématicien Pierre-Simon de Laplace, en 1814, pousse l’autre idée à son terme. Il s’appuie sur l’astronomie et sur la loi de la pesanteur universelle, celle de Newton. Une intelligence qui connaîtrait, à un instant donné, toutes les forces de la nature et la position de chaque chose pourrait, selon lui, tout calculer : « rien ne serait incertain pour elle, et l’avenir comme le passé, serait présent à ses yeux » (Wikisource). C’est le déterminisme : ce qui arrivera découle de ce qui est, et peut donc se prévoir.
Les économistes appliquent ensuite le découpage à la fabrication. En 1776, Adam Smith ouvre La Richesse des nations sur une manufacture d’épingles. Le travail de faire une épingle y est « divisé en dix-huit opérations distinctes ou environ ». Dix ouvriers y produisent « plus de quarante-huit milliers d’épingles dans une journée », alors que chacun, seul, n’en aurait peut-être pas fait vingt (Wikisource). En 1832, le mathématicien anglais Charles Babbage reprend l’exemple de Smith dans son Traité sur l’économie des machines et des manufactures. Pour chaque opération de la fabrication des épingles, il dresse un tableau « du temps qu’elle exige, et de son coût » (Projet Gutenberg). Qui connaît le temps et le coût de chaque opération peut calculer d’avance ce que coûtera la fabrication entière.
Rien ne prouve que Frederick Winslow Taylor ait lu Babbage. Des chercheurs en gestion voient pourtant en Babbage un pionnier de l’organisation de la production (Lewis, 2007). Il est très probable que ces idées soient parvenues à Taylor par le milieu des ingénieurs de son temps, où mesurer les coûts de fabrication devenait un sujet à part entière. En mai 1886, à Chicago, l’industriel Henry Towne présente à la société américaine des ingénieurs mécaniciens, l’ASME, une communication intitulée « L’ingénieur comme économiste ». Il y demande aux ingénieurs de s’occuper aussi de la gestion des ateliers et d’en mesurer les coûts. Le compte rendu de la séance cite Taylor parmi les ingénieurs qui ont pris part à la discussion (Transactions of the ASME, vol. 7). En 1921, une revue industrielle estimait que cette communication avait « probablement inspiré » Taylor à consacrer sa vie à l’organisation des ateliers (Wikiquote).
Pour fabriquer des épingles par milliers, cette vision du monde est d’une grande efficacité : chaque geste se répète, donc se mesure et se prévoit. Taylor en a fait une méthode de gestion. C’est cette méthode qui, aujourd’hui encore, sert à planifier des ouvrages que personne n’avait encore réalisés.
Au début du XXe siècle, dans les ateliers et les aciéries américaines où il travaille, l’ingénieur Frederick Winslow Taylor fonde l’organisation scientifique du travail : chaque tâche est chronométrée, puis prescrite d’avance. Dans son livre de 1911, il écrit que la tâche précise « non seulement ce qui doit être fait, mais comment le faire, et le temps exact accordé pour le faire » (Projet Gutenberg). Henry Gantt, dont le diagramme sert encore à planifier les projets, a commencé comme assistant de Taylor (Wikipédia). Fixer d’avance la durée et le contenu d’un ouvrage jamais réalisé, ce n’est ni plus ni moins que du taylorisme, appliqué à ce qui ne se répète pas.
Frédéric Leguédois, coach agile et formateur, aborde ce point dans sa conférence « Éloge de la simplicité ». Dans un contexte imprévisible, dit-il, les approches prédictives « s’apparentent bien plus à des pratiques divinatoires qu’à une approche scientifique ».
Si tout peut être calculé, tout n’est pas bon à être calculé.
On nous demande souvent des chiffres. On veut faire fonctionner les choses avec des chiffres, en pensant faire de la science. Mais à vouloir des chiffres à tout prix, on a fini par faire de la numérologie.
Certaines équipes ont cessé d’estimer et comptent plutôt les fonctionnalités terminées, pour en projeter le rythme sur la suite. C’est plus solide qu’une supposition, mais cela reste une prédiction, comme nous l’expliquons dans notre article sur l’approche prédictive et l’approche adaptative.
Ces dates et ces budgets ne restent pas dans les bureaux : ils sont annoncés. Annoncer au public une date que l’on ne peut pas garantir, qu’il s’agisse d’un jeu, d’une ville ou d’un logiciel, c’est demander à ceux qui l’attendent de patienter, et aux investisseurs de miser sur un ouvrage qui n’existe pas encore, en comptant sur un retour à cette date. C’est donc faire une promesse. Et quand on la sait irréaliste au moment de l’annoncer, pour gagner la confiance des investisseurs, ce n’est pas une promesse, c’est de la tromperie.
Nous ignorons ce que savait l’éditeur de GTA VI à chaque date annoncée. Le 10 septembre 2025, Take-Two présentait encore à ses investisseurs une sortie de GTA VI le 26 mai 2026. Huit semaines plus tard, elle passait au 19 novembre 2026.
En marketing, on a banalisé le mensonge : on distingue les gros mensonges des petits, comme si les seconds étaient sans conséquence. En réalité, il n’y a pas de distinction à faire entre les deux.
Lorsque l’on se met à la place de ceux à qui l’on a fait ces promesses, les joueurs qui ont attendu, les investisseurs qui ont établi leurs prévisions sur cette date, celui qui a promis perd sa crédibilité. Et pour les contribuables, qui voient leur argent englouti dans des projets finalement abandonnés, c’est inacceptable. C’est un manque de respect pour son prochain, et envers soi-même.
Il y a toujours une alternative. Arrêtons de vendre du rêve aux gens. Arrêtons de les duper. Promettons moins et délivrons plus, au lieu de promettre beaucoup et de délivrer moins.
Le jeu doit avancer, évidemment. Mais si l’on ne sait pas combien de temps son développement prendra, et si l’on refuse de faire des promesses irréalistes, comment s’y prendre ?
On développe d’abord dans un environnement contrôlé, restreint et confidentiel, pour que le jeu soit jouable le plus tôt possible : pas 100 % de l’histoire, mais une partie réellement achevée, 10 % d’un jeu qui fonctionne. S’il faut des fonds, une poignée d’investisseurs de confiance joue à cette version privée, qui prouve que l’on peut déjà gagner de l’argent avec ce qui est terminé. Ils décident de continuer à investir sur un jeu utilisable, et non sur un planning.
En parallèle, on communique énormément sur tout ce qui peut être divulgué, sans rien mentionner de confidentiel : de vrais extraits du jeu, les coulisses de sa conception. Le public voit que le jeu est toujours en développement, que l’équipe affronte des difficultés, et qu’il avance. Le message est simple : jugez par vous-même, le jeu est déjà remarquable tel qu’il avance. Les investisseurs, eux, voient que les joueurs ont hâte de l’avoir entre les mains.
C’est seulement à ce stade que vient la question de la date, et elle n’est plus essentielle. Une date ferme ne peut être tenue que pour un jeu déjà terminé. Si l’on tient à en donner une, on donne une approximation, une fourchette : une sortie visée entre tel et tel trimestre, présentée comme un objectif, pas comme une promesse. Et l’on rassure aussitôt avec ce qui est certain : telle partie du jeu est terminée, et les joueurs l’attendent.
Des studios travaillent déjà ainsi, en vendant leur jeu inachevé en « accès anticipé », puis en le complétant au fil des mises à jour.
Larian Studios met en vente Baldur’s Gate 3 en accès anticipé le 6 octobre 2020, avec son premier acte seulement, environ 25 heures de jeu (Game Informer). Le jeu complet, sorti le 3 août 2023, est élu jeu de l’année aux Game Awards 2023 (TechRadar).
Supergiant Games ouvre Hades en accès anticipé en décembre 2018, puis publie une mise à jour majeure « tous les mois ou tous les deux mois », selon son directeur créatif, Greg Kasavin (GeekDad) ; le jeu dépasse le million d’exemplaires vendus quelques jours après sa sortie, en septembre 2020 (PC Gamer).
Le studio de Factorio, lui, publie chaque vendredi depuis 2013 ce qui a avancé dans la semaine, et ce jusqu’à la version finale de 2020 (Factorio).
L’éditeur coréen Krafton pousse la démarche à l’extrême avec inZOI, un jeu de simulation de vie dans la lignée des Sims. Le jeu sort en accès anticipé le 28 mars 2025, avec une feuille de route publique, et son studio annonce vouloir « continuer à communiquer activement avec les joueurs » (Krafton). Il se vend à un million d’exemplaires en une semaine (ActuGaming). Certains estiment que tout montrer ainsi tue la surprise. Nous n’irions pas jusque-là, mais c’est une possibilité, et le jeu a trouvé son public.
Le Manifeste pour le développement Agile de logiciels le dit en une phrase : « Un logiciel opérationnel est la principale mesure d’avancement. »
Beaucoup de rapports d’avancement mesurent autre chose. Prenons des chiffres ronds : une liste de 100 fonctionnalités, établie au début du projet. Au bout de quelques mois, 50 d’entre elles sont développées à moitié. Le rapport annonce 25 % du projet accompli, ou la moitié des fonctionnalités entamées. Pourtant, aucune ne peut servir. Si le budget s’épuise ce jour-là, il n’y a rien d’utilisable à mettre entre les mains des utilisateurs, ni rien de commercialisable.
Ce rapport est celui de l’approche prédictive : une liste complète dressée d’avance, et un avancement compté en pourcentage de cette liste. A contrario, l’approche adaptative ne commence pas par une liste de tout ce que l’application devra faire. Elle commence par une question : de quoi les utilisateurs ont-ils besoin pour qu’une première promesse, minimale, soit tenue ? Les réponses forment le produit minimum viable, le MVP : quelques fonctionnalités essentielles, choisies avec les utilisateurs et à partir des meilleures informations dont on dispose.
On les termine entièrement, qualité logicielle incluse : le logiciel doit pouvoir évoluer facilement après les retours des utilisateurs, puisque ces fonctionnalités en deviennent le cœur, comme l’explique Allen Holub, développeur et formateur américain (blog.holub.com). On met ainsi à la disposition des utilisateurs, des clients, un véritable produit utilisable, le plus tôt possible.
À partir de là, ce sont leurs besoins qui guident la suite. Au fil de la vie du logiciel, de nombreuses fonctionnalités seront ajoutées, d’autres évolueront, d’autres encore seront retirées parce qu’elles ne servent pas : le projet ne s’arrête pas au MVP. La suite se planifie, mais par priorités : pour chaque besoin, on se demande ce que coûte le fait de ne pas l’avoir encore en service. Cet ordre de priorités reste souple, pour garder la capacité de s’adapter à la réalité plutôt que de suivre un itinéraire qui mène à l’échec. C’est ainsi qu’une application devient entièrement utilisable sans liste de 300 fonctionnalités dressée d’avance. Et si le budget s’épuise en chemin, ce qui est en service sert déjà, et peut être commercialisé : l’investissement n’est pas perdu.
Un projet confidentiel n’a pas à être présenté au public. Son avancement se mesure quand même au logiciel utilisable : ceux qui doivent juger de cet avancement s’en servent en situation réelle. Une démonstration ne suffit pas. Dans beaucoup de projets, il est courant que la démonstration, menée par le chef de projet, suive un parcours préparé, qui passe par ce qui fonctionne et évite les anomalies qui révéleraient que l’application n’est pas encore utilisable, donc pas terminée. Seul l’usage réel montre où en est le logiciel. Pour votre application, la première question n’est donc pas « combien de fonctionnalités ? », mais « de quoi vos utilisateurs ont-ils besoin pour commencer ? ». Dans une cathédrale, c’était le chœur.
Derrière ces dates repoussées, il y a une question sur la nature humaine : le besoin constant de connaître l’avenir, de chercher la prévisibilité.
Parlons d’un livre ancien, un livre de sagesse qui, malgré ses plus de deux mille ans, est toujours d’actualité : la Bible. On y lit dans l’Évangile de Matthieu, au chapitre 6, verset 34 : « Et ne vous inquiétez jamais du lendemain, car le lendemain aura ses propres inquiétudes. À chaque jour ses problèmes. » Autrement dit : s’occuper aujourd’hui de ce qu’on peut faire pour les problèmes d’aujourd’hui.
Frédéric Leguédois cite ce même verset dans sa conférence « Éloge de la simplicité ». Il y décrit aussi le planning d’un projet : « Le planning, c’est un amas d’informations qui sont inutiles aujourd’hui et qui sont fausses à partir de demain. »
Reconnaissons avec modestie que nous n’avons pas le contrôle sur tout. Prétendre le contraire revient à vendre une certitude que personne ne possède.
Lâcher prise sur la prédictibilité ne veut pas dire avancer au petit bonheur la chance. C’est se préparer autrement, anticiper autrement. D’ailleurs, ce que l’on appelle couramment un plan, un planning dressé d’avance, n’en est pas un. En cartographie, un plan représente un terrain que l’on a déjà parcouru : pour dresser le plan d’une ville, il faut l’avoir arpentée et mesurée. Sans mesures, pas de plan. Or le planning d’un ouvrage jamais réalisé décrit un terrain que personne n’a encore arpenté. Allen Holub l’écrit à propos des feuilles de route : « Une feuille de route est un pari, pas un plan » (LinkedIn).
Lâcher prise, c’est accepter la réalité telle qu’elle est pour se concentrer sur ce qui compte, plutôt que de découvrir après coup que la promesse n’était pas tenable.
Comment gérer l’incertitude quand on construit ce que personne n’a encore réalisé ? Intéressons-nous à la manière dont on bâtissait les cathédrales. Les cathédrales gothiques sont reconnues comme des œuvres sans précédent, et certaines ont été pendant des siècles les plus hauts édifices construits par l’homme. Comment les finançait-on ? Qui en décidait le plan ? Comment menait-on un chantier sur plusieurs générations de bâtisseurs ? Les comptes médiévaux ne nous sont parvenus qu’en partie, mais ce qui en reste montre un savoir-faire.
L’argent. Une cathédrale se construisait avec l’argent qui rentrait : les revenus de l’évêque et des chanoines, les prêtres attachés à la cathédrale, les dons et les legs des fidèles (Vroom).
À Strasbourg, des chanoines créent en 1226 l’Œuvre Notre-Dame, une institution chargée de financer le chantier. Elle existe toujours, administrée par la ville, et des dons assurent encore une partie de ses recettes (Ville de Strasbourg).
À Chartres, après l’incendie de 1194, la reconstruction va vite grâce aux « énormes moyens financiers qu’avaient su réunir les chanoines » (Encyclopædia Universalis). Selon une tradition souvent reprise, les marchands de la ville y auraient offert 42 vitraux (World History Encyclopedia) ; les historiens divergent, certains y voyant plutôt des dons du chapitre.
Il semblerait aussi que l’Église ait encouragé les dons par des indulgences : pour Troyes, un relevé d’archives publié par un site d’histoire locale cite des légats du pape qui en accordent, dès 1213, à ceux qui contribuent aux dépenses du chantier (Aube Généalogie).
À Laon, selon un récit écrit une trentaine d’années après les faits, des chanoines auraient promené les reliques de leur cathédrale incendiée à travers le nord de la France et le sud de l’Angleterre, en 1112 et 1113, pour réunir des fonds (Wikipédia).
Quand l’argent manquait, les travaux ralentissaient, et parfois s’arrêtaient pour longtemps.
Le plan. Il n’était pas figé le jour de la première pierre. À Reims, l’archevêque décide en mai 1211 de reconstruire la cathédrale. Quatre maîtres d’œuvre, les architectes de l’époque, se succèdent sur le chantier ; le sanctuaire est achevé en 1241, le gros œuvre en 1275 seulement (INA).
À Strasbourg, le musée de l’Œuvre Notre-Dame conserve une trentaine de dessins d’architecture, dont certains mesurent jusqu’à 4 mètres de haut. Ils documentent, écrit le musée, la relation aux « commanditaires que ces projets spectaculaires devaient convaincre » (Musées de Strasbourg). Le maître d’œuvre proposait, ceux qui payaient décidaient. Qui a dessiné ces plans ? La tradition en attribue un à Erwin de Steinbach, premier maître d’œuvre connu de l’Œuvre Notre-Dame ; mais trois plans de la façade nous sont parvenus, et les historiens ne s’accordent pas sur celui qui serait de sa main (Wikipédia).
Le chantier. On commençait le plus souvent par le chœur, la partie de l’église où se célèbrent les offices, et on s’en servait dès qu’il était bâti.
À Notre-Dame de Paris, le chantier s’ouvre en 1163 ; l’autel du chœur est consacré en 1182, et un mur provisoire le sépare du chantier de la nef (Mullins et Katz).
En Allemagne, à Cologne, la première pierre est posée en 1248 ; le chœur est consacré en 1322, et un mur provisoire le ferme à l’ouest. Le chantier s’arrête ensuite pour plus de trois cents ans, mais les sources ne s’accordent pas sur la date : après 1520 selon le site de la cathédrale (cathédrale de Cologne), dès 1473 pour la tour sud selon d’autres chronologies (Wikipédia). Quand il reprend en 1842, on suit le plan de façade dessiné vers 1280, haut de plus de 4 mètres (atelier de la cathédrale de Cologne). Il avait été retrouvé en deux morceaux : l’un en 1814 dans le grenier d’une auberge de Darmstadt, l’autre à Paris en 1815, selon le Freies Deutsches Hochstift (musée du romantisme allemand) ; d’autres sources datent la seconde découverte de 1816. Le mur provisoire du chœur n’est abattu qu’en 1863, plus de cinq siècles après sa construction. Une association de donateurs, le Zentral-Dombau-Verein, apporte environ 60 % du financement, et la cathédrale est achevée en 1880.
De retour en France, à Beauvais, les voûtes du chœur s’effondrent en 1284, puis la tour de la croisée en 1573. Le chantier s’arrête alors définitivement : la nef n’a jamais été construite (ministère de la Culture).
Les records. Ces cathédrales étaient des œuvres d’art et d’ingénierie. Bâties de cette manière, par parties et au rythme des dons, certaines ont pourtant battu des records de hauteur. Aucun registre officiel ne tranche ; les dates qui suivent sont celles de la chronologie que reprend Wikipédia (Wikipédia). La cathédrale de Lincoln, en Angleterre, dont la reconstruction avait elle aussi commencé par le chœur, entre 1192 et 1210 (Wikipédia), aurait détenu le record de hauteur avec sa flèche, de 1311 à sa chute en 1548, avec environ 160 mètres, un chiffre que des historiens mettent en doute. Viendraient ensuite, notamment, Beauvais de 1569 à 1573, Strasbourg et ses 142 mètres de 1647 à 1874, Rouen de 1876 à 1880, puis Cologne et ses 157 mètres jusqu’en 1884. Pour Strasbourg, nous n’avons trouvé aucune page officielle qui confirme ces dates.
À Cologne, l’atelier de la cathédrale n’a jamais fermé. Son architecte déclare les travaux terminés en 1902 ; l’atelier lui-même juge cette déclaration démentie quatre ans plus tard. Une centaine de personnes y travaillent aujourd’hui (atelier de la cathédrale de Cologne) : la cathédrale sert depuis 1322, et le soin apporté à l’édifice n’a jamais cessé.
Il en va de même d’une application. Elle n’est pas livrée une fois pour toutes, puis abandonnée : elle vit, et doit être adaptée aussi longtemps qu’elle sert, comme un édifice demande de l’entretien.
Sur ces chantiers, les bâtisseurs ne savaient pas quand l’ouvrage serait achevé. Ils commençaient par l’essentiel : ce sans quoi l’édifice n’aurait été qu’une coquille vide, inutilisable, dont les premières générations n’auraient même pas profité. Ils avançaient au rythme de l’argent reçu, et soumettaient leurs plans à ceux qui payaient.
Alors que s’est-il passé ? Pourquoi annonce-t-on, pour un ouvrage que personne n’a encore conçu, une date et un contenu fixés d’avance ? Avons-nous perdu un savoir-faire, celui de construire par parties dont chacune sert ? Ou une valeur ?
D’un côté, il y a l’honnêteté, et un raisonnement de fond qui montre comment gérer l’incertitude et construire malgré elle quelque chose qui a de la valeur. De l’autre, il y a le désir d’entendre ce qui rassure : tout, tout de suite, avec le sentiment que tout est sous contrôle. Le sociologue allemand Hartmut Rosa décrit une société prise dans une accélération permanente (La Vie des idées) ; Nicole Aubert, en France, parle d’un « culte de l’urgence » (BnF). Un indice de cette impatience se mesure même : en 2012, une étude portant sur 23 millions de visionnages de vidéos en ligne a montré que les spectateurs commencent à abandonner si la vidéo ne démarre pas en deux secondes, et que chaque seconde d’attente supplémentaire augmente le taux d’abandon d’environ 5,8 % (ScienceDaily).
Devenons-nous impatients ? Voulons-nous à tout prix des délais, en pensant que c’est réaliste ? Et pourquoi l’acceptons-nous, comme clients, comme investisseurs, comme contribuables ?
Il n’y a probablement, à l’heure actuelle, pas de réponse définitive. Néanmoins, en ce qui nous concerne, nous avons pris position.
Chez DEVEDANOS, nous développons votre logiciel sur mesure, utilisable en un mois, pour un budget mensuel fixe, et l’ajustons en continu à l’évolution de votre activité. Nous fixons ensemble le montant et le problème que votre application doit résoudre. Notre approche prédit ce qui est prévisible : le budget mensuel et les jours de développement par mois. Elle ne cherche pas à prédire l’imprévisible : ce que vos utilisateurs feront d’une fonctionnalité avant de l’avoir entre les mains. Frédéric Leguédois parle à ce sujet d’un « fonctionnement sans aucune projection » (leguedois.fr).
Votre enveloppe achète du travail pour atténuer ce problème en permanence, dès le premier jour de développement. Nous visons sa résolution complète, sans pouvoir la garantir ni la dater. Les utilisateurs de votre application s’en servent dès le premier mois de développement, et c’est leur usage qui définit la ou les fonctionnalités suivantes.
Il n’y a plus d’estimation à dépasser. Il y a un budget que vous avez choisi, et un logiciel dont vos utilisateurs se servent déjà.
Notre guide détaille les questions à poser avant de signer un devis pour le développement de votre outil sur mesure.
Votre projet a déjà dépassé son budget, et l’application est à reprendre ? Notre page reprise et refonte d’application explique comment nous reprenons une application existante.
Vous avez un logiciel à faire développer, ou un outil qui ne suit plus votre activité ? On en parle ?
Le 21 octobre 2026, PHP a corrigé deux failles critiques, le même jour que GitLab et Node.js. Qui est concerné, que faire le jour même, et comment limiter les dégâts d'une faille.
Livraison continue (continuous delivery) et déploiement continu (continuous deployment) ne diffèrent que d'un geste. Pourquoi un petit changement fréquent est moins risqué qu'un gros, sources à l'appui.
Feature flag, c'est quoi ? Quatre types de toggles, ce qu'il faut essayer avant d'en ajouter un, et sept anti-patterns qui font tourner du code jamais testé.