Prototyper les modifications du territoire : application concrète du Design Thinking aux travaux publics

Note préliminaire : cet article effleure le sujet du Design Thinking dans les couches basses des télécoms, et il y aura sans doute d’autres réflexions sur le même thème. Si vous souhaitez échanger sur ce sujet, n’hésitez pas à me contacter !

La réalisation de travaux d’ampleurs, et plus particulièrement le déploiement d’infrastructures, est vis-à-vis des parties prenantes qui seront concernés à la croisée de deux sentiments souvent assez forts mais toujours opposés : la peur de de l’impact, et la volonté de toucher les fruits de ce projet d’intérêt général. Le résultat, c’est le fameux effet NIMBY, défini par Wikipedia :

Le terme ou les expressions effet Nimbysyndrome Nimby, sont utilisés généralement pour décrire soit l’opposition de résidents à un projet local d’intérêt général dont ils considèrent qu’ils subiront des nuisances, soit les résidents eux-mêmes.

J’ajouterais à cette définition que les élus locaux sont une des parties prenantes qui, si elle n’est pas gérée correctement, peut être un véritable levier négatif.

Dans tous les cas, c’est un échec, et pour ceux qui ont un réseau à déployer, ce sont des études à refaire, des plannings percutés, des délais qui courent, et une pression supplémentaire qui monte et qui pousse parfois à réaliser des choix techniques que l’histoire jugera assez durement.

Une des solutions pour lutter contre ce rejet, qui est souvent lié à une communication défaillante, est la co-construction avec les parties prenantes. Malheureusement, cette notion, qui est aujourd’hui parfaitement intégrée dans les réflexions sur la manière de gérer les transformations (le paradigme expérientiel du changement) n’est pas du tout intégré dans les processus qui sont aujourd’hui en vigueur dans les déploiements d’infrastructures à grande échelle. Ce sont des cas où la partie prenante qui est confrontée à la nuisance n’a été ni décideur, ni demandeur, ni sollicité durant la phase de conception globale. Cette situation est courante dans les télécoms : déploiement de fibre optique, déploiement d’un réseau de relais radio, …

Quelles pistes d’amélioration ?

C’est un sujet très vaste et qui dépasse largement le cadre de cet article. Il y a de nombreuses idées d’autres secteurs à adapter dans notre domaine d’activité, et nous ne les parcourerons pas toutes aujourd’hui…

La première étape – et sans doute la plus simple – c’est de savoir comment partager efficacement le plan d’un projet. C’est la que nous rejoignons la notion de Design Thinking : avoir une représentation sous forme de « maquette » permet de co-construire le projet, de le représenter, de se l’approprier, bref de le faire adopter plus facilement. L’objet physique permet de créer un lien, bien plus qu’un plan papier et oh combien plus qu’une projection sur un vidéoprojecteur.

Hélas aujourd’hui, encore trop de projets sont présentés sous forme de plans d’exécution sur fond de cadastre, qui sont au mieux lisibles par ceux qui connaissent bien le détail de la commune et qui ont l’habitude de tels plans.

Exemple ici avec un réseau d’eau potable, similaire dans la logique aux déploiements fibre.

Légèrement plus ergonomiques sont les tracés projets sur des plans Google Maps (ça arrive, l’aspect professionnel laisse un peu a désirer pour des travaux qui se chiffrent en centaines de milliers d’euros…), voire des fonds de plans de l’IGN via Géoportail (un peu mieux, mais quel gâchis de « redessiner » en permanence les tracés). On a parfois la chance d’avoir un orthophotoplan, et ce d’autant plus qu’il est de plus en plus simple d’en réaliser à bas cout avec des drones grand public.

Cependant, il existe aujourd’hui des solutions techniques qui permettent de créer un véritable objet représentant le territoire. Un objet que l’on peut faire circuler de main en main, qui par son format concret permet d’instaurer un effet « wow » : il s’agit de l’impression en 3D d’une carte du paysage avec l’emprise des bâtiments existants.

C’est une superbe opportunité de présenter un projet, et pourquoi pas d’affiner les détails avec les parties prenantes concernées, celles qui connaissent le territoire et pourront être force de proposition pour affiner un APD par exemple. C’est un excellent moyen d’aider les intervenants à construire une meilleure image mentale de la zone très rapidement.

Comment ça marche ? Les fichiers qui sont ci dessus sont générés par Touch Mapper, une application web qui a pour but de générer facilement des fichiers permettant d’imprimer des cartes sensorielles pour les déficients visuels. Ce qui explique que la hauteur des bâtiments n’est pas prise en compte. Il est possible de faire beaucoup plus réaliste, comme le montre la page du wiki OpenStreetMap dédiée à ce sujet, mais c’est plus complexe et requiert une chaine logicielle avec des modeleurs 3D tels que Blender.

File:3d print blender3d-fin.png
Même si ca vaut le coup, on sort du quick win pour aller vers l’investissement en temps non négligeable…

Le vrai intérêt de la solution de Touch Mapper, c’est l’immédiateté et la facilité de la chose ; de l’adresse au fichier STL prêt à être imprimé, il n’y a que quelques secondes.

Quel usage pour les déploiements de télécom ?

Au-delà de l’évidente envie d’imprimer les alentours de son logement, ou son parc préféré, ou encore un atoll paradisiaque que l’on préférerait fouler du pied mais que l’on est déjà content de caresser du doigt, les usages suivant sont pertinents dans un contexte professionnel dans les télécoms :

  • Implantation de bâtiments techniques « conséquents » : NRO, datacenters. On peut faciliter les démarches de négociations foncières avec un tel outil sur plusieurs niveau :
    • Impression de la zone, et échange avec les technicien de la collectivité locale sur le meilleur endroit ou on peut mettre en place un bâtiment ou une grosse armoire ;
    • Une fois qu’elle est positionnée, intégration paysagère avec un modeler 3D pour générer non seulement une vue 3D qui permet de se rendre compte de l’impact, mais aussi le résultat final physique.
  • Positionnement des mats d’antenne et sites radio : représentation du vis-à-vis, visualisation de l’amélioration de la couverture, …
  • Travaux de VRD pour déploiement de la fibre : impact, visualisation chantier, préparation à la vie pendant les travaux dans les zones concernées
Central Park, Manhattan, au bout des doigts…

Les usages dépassent largement le sujet du déploiement dans les télécommunications, voici quelques exemples :

  • Couches plus hautes : lors de la constructions de bâtiments, ou de ponts, on peut intégrer directement les résultats finaux dans le terrain ; de nos jours tout ce qui est livré doit l’être en STL, et on peut l’intégrer sur le résultat final ;
  • Couches purement travaux : on peut se servir d’une telle simulation pour l’impact travaux, par exemple la gestion des gravats. Certains chantiers génèrent beaucoup de matériaux de déblais
  • Couches basses : avec les informations d’infrastructures qui sont comprises dans OpenStreetMap grâce aux travails de passionnés (lignes électriques, conduites forcées, pipelines de gaz ou d’hydrocarbures, lignes de trains,…) de superbes visualisations peuvent être construites qui permettent de prendre la mesure de l’existent et de penser des schémas cohérents.

Pour faire simple, on peut considérer qu’avec la représentation sémantique du territoire d’OpenStreetMap, on a quasiment l’opportunité d’imprimer en 3D le résultat d’un SELECT dans une base de données… Et c’est très puissant.

Pourquoi est-ce bien plus qu’une maquette d’architecte ?

Peut être vous demandez-vous en quoi c’est fondamentalement différent d’une maquette faite par un cabinet d’architecte ; l’objet final est similaire, l’objectif est le même mais il y a une énorme différence : le coût.

Une maquette, c’est une véritable oeuvre, faite souvent par des artisans spécialisés dans des temps conséquents et dont le coût est de plusieurs milliers d’euros. Elle est donc faite pour vendre un projet, et un projet aussi « contraint » spatialement que possible tant le prix est au cube du diamètre de l’objet construit.

Dans notre cas de figure, c’est tout le contraire : on cherche un système qui est rapide à réaliser, qui ne craint pas le contact physique et dont le cout est moindre ; et à plus forte raison que celui qui portera la charge financière n’est pas forcément le maître d’ouvrage, mais peut être un prestataire en charge de la négociation foncière, ou le titulaire d’un lot du marché. Ces derniers n’ont plus à convaincre un acheteur d’investir, mais doivent toujours persuader une partie prenante non incluse dans le deal initial de ne pas s’y opposer tant son pouvoir de nuisance pourrait être désastreux pour l’équilibre global.

On parle ici d’un cout de production de l’ordre de 50 €, et d’une facilité de modéliser enfantine : avec un marqueur, avec du papier, avec un SRO imprimé en 3D à l’échelle… On est dans une échelle de coût qui permet d’imaginer des schémas nouveaux tant l’importance de la négociation foncière est clé (et facteur d’économies, ou au contraire de gabegies) dans les déploiements FttH. Imprimer 10 maquettes similaire pour un déploiement correspondant à une zone arrière de NRO n’est pas un problème ; ce ne serait pas la même chose avec une maquette traditionnelle…

A noter que les architectes et urbanistes peuvent bien entendu s’emparer dès maintenant des ses possibles pour encore améliorer leurs maquettes actuelles !

De l’effet vertueux dans la ville

Enfin, un des externalités positives inhérente à cette pratique, si elle tend à se généraliser, va être l’augmentation de la contribution à OpenStreetMap par des entreprises qui n’auraient pas forcément investi dans son renseignement hors de ce projet.

En effet, plus la carte est à jour, plus les données sont renseignées, meilleur est le rendu : la contribution par l’acteur qui cherche à communiquer vis à vis des utilisateurs du territoire est une véritable création de lien entre les deux, qui permet de transcender les simples travaux pour créer un véritable projet de territoire, à la fois physique et numérique.

OpenStreetMap, le socle du « digital twin » ?

La suite de cette réflexion est l’utilisation Open Street Map comme un support pour la création de digital twin pour permettre de modéliser les changements qui peuvent être apportés à la ville (urbanisme, transport en commun, impact des politiques « vertes », co-construction avec les citoyens, …)

Le meilleur exemple existe déjà, sous forme d’un projet expérimental, qui n’est malheureusement plus développé : il s’agit de osmgo.org, qui utilise les données d’Open Street Map, avec des attributs un peu plus complets, pour recréer un double virtuel de n’importe quelle ville.

Représentation vue de la Saone de la place Bellecour à Lyon via osmgo.org, de l’intérêt de la modélisation des arbres !

Toutes les impressions ne se valent pas…

Les bureaux d’études (au moins dans le FttH) ont peu à peu abandonné le traceur, qui finalement n’était plus à même de représenter l’intégralité et la richesse du contenu d’une base de données, tant nous avons des outils qui sont efficaces (ordinateur, mais aussi mobiles) pour représenter des plans en 2D, voir en 2,5D avec une flexibilité que ne permet pas le papier.

On peut par contre parier sur le fait qu’il faudra encore longtemps avant que nos moyens numériques puissent supplanter la sensation d’une maquette, et la capacité d’un objet physique à créer une représentation mentale permettant de construire collectivement autour d’une idée commune.

A mon sens, ces mêmes bureaux d’études devraient externaliser les traceurs qui sont aujourd’hui tout sauf un avantage concurrentiel ; il devraient limiter l’usage des imprimantes classiques qui nuisent à la transformation numérique, mais ils devraient se pencher sur l’impression 3D, car elle peut être un levier de leur transformation.

Ressources supplémentaires

Ce sujet vous parle ? Vous avez une idée à implémenter dans un de vos projets et un accompagnement vous intéresse ? Nous pouvons prévoir un temps d’échange…

L’Open Source dans le déploiement telecoms, pour demain grâce à Etalab ?

Conséquence de la loi pour la République Numérique (2005, principe de gratuité en 2015), le sujet de l’OpenData avance en France. Certes pas toujours aussi vite qu’on le souhaiterait, mais ce mouvement est une véritable lame de fond dont les effets se font déjà ressentir et qui est en passe de servir de support à une révolution de la manière dont les services sont rendus.

Extension logique, les développements réalisés pour le compte d’organismes de l’Etat devraient également être diffusés. Il y a eu plusieurs précédents (simulateur d’impôts, Parcoursup entre autres) mais pas d’initiatives aussi généralisées et passant pas une plateforme dédiée, même si une page contenant tous les liens vers les forges publiques est maintenue. Toutes les collectivités ne sont pas en concurrence, et il est illogique que Lyon paie pour ce qu’aurait déjà financé Paris (et une plus petite collectivité à plus forte raisons), et que des prestataires facturent plusieurs fois le même développement.

Etalab, la mission qui maintient data.gouv.fr a créée une nouvelle plateforme pour recenser et stocker tous ces logiciels : https://code.etalab.gouv.fr/fr/repos

C’est le début, et il n’y a pas encore grand chose (on est loin d’une approche basée sur une synchronisation de tous les GitLab des services de l’Etat), mais c’est déjà intéressant parce que ca nous donne une bonne idée de quels services sont les plus « ouverts ». C’est sans doute dans ceux là qu’il faut aller chasser les bonnes pratiques de transformation numérique du reste de notre administration.

Etalab, qui remplit décidément très bien sa mission, a mis en place un questionnaire qui permet en quelques questions de savoir si un logiciel est diffusable. Les clauses sont assez larges ; même dans le cas ou des briques sont sous licence, elles peuvent être enlevées tandis que le reste du logiciel doit être publié si il n’est pas vidé de son sens.

Il est disponible ici : https://guide-juridique-logiciel-libre.etalab.gouv.fr/#0

Et dans le domaine des télécoms ?

État des lieux : on ne trouve aujourd’hui aucune contribution dans le domaine télécom / génie civil, ni sur la liste des diffuseurs de logiciels ni sur la nouvelle plateforme d’Etalab.

Le déploiement de réseaux télécom est un grand consommateur de data. C’est aussi un énorme consommateur d’algorithmes, allant des configurations d’ETL aux requêtes SQL qui permettent d’automatiser des contrôles sur des bases, plugins QGIS divers et variés, scripts d’adaptation des PIT, outils de gestion de la documentation, outils de contrôles de routage, VBA de contrôles financiers, et sans doute beaucoup d’autres.

Ces outils sont certes présents chez les entreprises (et c’est un avantage stratégique pour ceux qui en ont de bons…) ainsi que chez les maîtres d’ouvrage dans le cas des RIP, ou à l’ARCEP ou chez d’autres contrôleurs / régulateurs / financeurs. Parmi ces derniers, beaucoup de structures publiques : en tout logique elle devraient publier leurs codes sources. Intérêts évidents :

  • Faire en sorte que d’autres collectivités ne paient pas plusieurs fois pour les mêmes outils, mais passent leurs budgets supplémentaires dans l’adaptation desdits outils ainsi que leur extension. Ce qui permettra de n’avoir que des projets public state of the art ;
  • Encourager les développements sur des socles sains et avec des bonnes pratiques de développement : évite les codes « poubelles » qui ne peuvent être réutilisés ;
  • Auditer fonctionnellement ces outils, notamment pour ceux qui ont un rôle contractuel ;
  • Plus de testeurs, plus de rapport de bugs, donc des outils plus robustes ;
  • Faire profiter à la filière de ces outils afin de produire collectivement les études (et les récolements) les plus aboutis possibles.
  • Et beaucoup d’autres, cf les argumentaires classiques de l’open source

Je suis à même de constater professionnellement la difficulté qu’ont les entreprises du secteur à travailler sur des formats « nouveaux », et l’impact financier sur certaines petites structures déséquilibre la filière entière tant elles ne sont pas a même de faire l’investissement nécessaire à l’usage de ce langage commun qu’est la base de donnée.

Facteur aggravant, GraceTHD v3 va sortir de manière imminente, et de nombreux outils du toolkit classique devront sans doute être revus avec cette nouvelle version dont les modifications structurelles sont assez importantes. C’est l’occasion de se préparer à faire des économies rapidement.

N’oublions pas que ce que nous vivons aujourd’hui avec le déploiement de la fibre optique préfigure le futur des travaux publics (le passage du monde Autocad vers le monde GIS en raccourci). C’est donc un sujet qui est d’ampleur nationale et qui est de nature à influer sur la compétitivité de nombreuses PME locales pourvoyeuses d’emploi sur tout le territoire.

Comment faire évoluer la chose ?

Nous pourrions réfléchir (et je vais attaquer rapidement à faire ma part) à une liste d’acteurs et donc d’applicatifs dont la diffusion pourrait être demandée.

La question qui se pose est celle de la liste des administrations à contacter, ainsi que des logiciels que l’on pourrait leur demander de diffuser. En effet, d’expérience, les « propriétaires de PI publique », comme on pourrait les appeler de manière générique, ne sont pas toujours enclins à livrer spontanément les données et codes sources. Qui dit absence de catalogue dit connaissance par contact… Et c’est là que nous pouvons collectivement faire quelque chose ; si vous travaillez avec des administrations vous savez quoi leur demander ; problème réglé !

En en discutant par mail, LinkedIn ou Twitter, on peut faire assez vite le tour.

Se pose bien sur la question du futur de ces codes sources, ou de comment faire vivre ces codes sources au delà de leur existence actuelle. Idées pêle-mêle :

  • Diffuser cette liste de logiciel auprès des parties prenantes : collectivités, conseils, entreprises du secteur, afin qu’elle soit utilisée au maximum ;
  • Faire en sorte que les entreprises qui utilisent aient aussi une démarche de contributeurs en fixant des bugs / mettant à jour des fonctionnements ;
  • On peut globalement espérer un développement de plusieurs briques autour de standards tels que Grace ou les plans Iti par exemple, qui fonctionneraient comme des communautés Open Source, voire gérées par un consortium, ou une commission d’Infranum, ou autre structure de la filière.

L’étendue des possibles dépasse bien évidemment le cadre de ce document et ne pourra être imaginé que collectivement ; mais il est certain qu’une des conditions favorisant le mouvement Open Source dans un domaine est la contribution significative d’un acteur qui fait le premier pas. Cet acteur pourrait être l’administration française.

Pour suggérer les codes sources manquants, on peut passer par le GitHub de la DISIC ou tout simplement contacter la structure en question, de manière individuelle ou via madada.fr.

Réponse anticipée aux critiques concernant la tendance à l’ouverture des données

Cette tendance de l’ouverture des logiciels du public n’a rien d’une exception française, ou d’un quelconque délire local et temporaire visant à empêcher les ESN et consultants de travailler comme on peut l’entendre. C’est un mouvement à l’échelle mondiale, un peu de lecture récente sur le sujet :

Quant à la crainte que cette initiative ne puisse se déployer largement à cause du fait que la plupart des prestataires de l’état commercialisent des codes sous licence, il faut agir en amont (et en urgence) : la commande publique peut et doit être utilisée comme un outil pour améliorer encore l’efficacité de l’action de l’Etat. C’est un sujet dont il faut se saisir, et un certain nombre d’actions existent dans ce domaine comme les Trophées de la commande publique qui peuvent certainement être mis à contribution.

On en parle ?