C’est ce que je veux explorer tout au long de ce blog. A partir de situations pénibles, concrètes, vécues par de petites agences d’architecture ou par des architectes indépendants, je vais tester différentes solutions qui pourraient les alléger : méthodes simples ou outils déjà disponibles facilement, mais aussi des prototypes qui pourraient être créés pour l’occasion.
Pourquoi me lancer dans ce projet ?
Quand j’exerçais comme architecte libérale, concevoir des projets n’était pas la partie la plus importante de mes journées. Il fallait aussi répondre aux emails, suivre les dossiers, préparer des candidatures, relancer, rédiger des comptes rendus, surveiller des échéances, retrouver une information … et bien sûr en essayant de ne rien oublier.
Je l’avoue, je me suis sentie bien souvent dépassée et seule. Il pouvait même m’arriver de me réveiller en pleine nuit et de lister les tâches qui m’attendaient le lendemain au lieu de compter les moutons …
Quand on travaille seul, ou dans une petite agence, avoir recours à des solutions de gestion d’agence toutes prêtes peut sembler superflu, tant dans l’usage que dans la dépense. Et devoir changer de mode de fonctionnement pour s’adapter à de nouveaux outils peut être perçu, à tort probablement, comme une perte de temps. Pour ma part, c’était système D : mon système fonctionnait cahin-caha, mais il fonctionnait.
Nous sommes d’accord qu’une grande partie du travail de gestion est indispensable pour la bonne santé de l’activité.
Mais est-ce que certaines de ces actions ne pourraient pas être simplifiées et d’autres déléguées, avec des solutions simples à mettre en œuvre et sans chambouler tout son fonctionnement ?
C’est cette question que j’ai décidé d’explorer dans ce blog IA et BTP.
Mes premières réflexions
Au départ, ma première intention était plus globale. Je voulais construire, petit à petit, pendant 52 semaines, un outil de gestion complet utilisable par un petit cabinet d’architecture. L’idée était ambitieuse : partir de zéro, structurer toute l’activité du cabinet, automatiser certaines tâches et utiliser l’IA lorsque cela pouvait être utile.
Ce premier travail m’a permis d’aller assez loin dans l’analyse du fonctionnement d’une petite agence. Mais il m’a aussi fait prendre conscience d’un problème dans ma propre démarche : je prenais le problème à l’envers.
J’ai donc décidé de changer d’approche.
Pourquoi construire un outil global était possible mais n’était pas la bonne réponse ?
En me formant à l’IA et au NoCode, j’ai découvert qu’il était possible de créer soi-même des outils. Chose que je n’aurais pas pu imaginer quelques années plus tôt.
J’en ai déjà fait l’expérience. J’ai construit ce blog en m’appuyant sur l’IA pour m’aider à adapter un cahier des charges technique à mes propres besoins. J’ai également créé un outil fonctionnel de gestion de patientèle pour un cabinet d’ostéopathe. Tout ça alors que je n’ai aucune compétence particulière en création de site ou en codage.
L’idée de construire un système de gestion pour une petite agence d’architecture ne me paraissait donc pas complètement déraisonnable sur le papier.
Mais en avançant dans le projet, j’ai fini par comprendre que je ne posais pas la bonne question.
Je cherchais à savoir jusqu’où je pouvais construire un outil. Je partais déjà de la solution. Alors que j’aurais dû commencer par me demander quels problèmes méritent réellement qu’on cherche une autre façon de faire.
Un outil peut parfaitement fonctionner sur le plan technique et ne résoudre aucun problème important.
Il peut aussi faire gagner quelques minutes tout en ajoutant de la complexité, de la maintenance ou un nouvel endroit où saisir des informations.
C’est comme concevoir un bâtiment qui ne répondrait pas aux besoins et ne tiendrait pas compte des contraintes ou de la réalité.
J’ai donc décidé de modifier mon point de départ.
Quelle méthode vais-je suivre ?
Je vais me focaliser sur un problème à la fois. Pour chaque irritant exploré, je chercherai d’abord quelles pistes méritent réellement d’être testées.
Selon le sujet, il pourra s’agir d’une façon différente de s’organiser, d’une fonction ou d’un service déjà accessible, ou encore d’un prototype construit dans le laboratoire lorsqu’une piste d’amélioration paraît intéressante.
Il n’y aura ni nombre minimum de solutions à tester, ni obligation de comparer plusieurs outils entre eux. L’objectif restera de comprendre ce qui pourrait réellement améliorer la situation, pas de désigner un « meilleur outil ».
Un laboratoire pour tester avant de construire
Je ne sais donc plus aujourd’hui quel sera le résultat final. Et c’est volontaire.
Plutôt que de consacrer 52 semaines à construire un système dont je ne sais pas encore s’il répond à un problème suffisamment important, je vais partir de situations beaucoup plus précises.
Certaines viendront de mon expérience du métier, d’autres de la veille que je mène sur les difficultés rencontrées par les architectes, de documents professionnels accessibles publiquement ou encore des questions soulevées en commentaires de mes articles.
Au départ, certaines ne seront donc que des hypothèses.
Méthodologie
Pour chaque hypothèse, l’objectif sera d’abord de comprendre précisément le problème, puis de sélectionner uniquement les pistes qui semblent suffisamment pertinentes pour mériter un test. Toutes les expérimentations ne suivront donc pas le même protocole et ne comporteront pas nécessairement plusieurs outils.
Je mesurerai ce qui change réellement :
- le temps nécessaire bien sûr
- les informations retrouvées ou perdues
- les oublis
- les ressaisies
- la visibilité de la prochaine action
- la complexité ajoutée
- le coût
- encore la maintenance nécessaire.
Et je documenterai aussi ce qui ne fonctionne pas.
Lorsqu’un outil existant paraît pertinent, je distinguerai également ce que j’ai simplement identifié et documenté de ce que j’ai réellement testé dans le laboratoire. Je ne souscrirai pas à un outil payant uniquement pour produire un test ou un article. Un test réel pourra s’appuyer sur :
- une version gratuite
- un essai gratuit suffisamment exploitable
- un service public ou libre
- ou éventuellement un accès fourni temporairement, en le précisant clairement
Un outil payant pourra donc être mentionné sans être présenté comme testé.
Un prototype ne sera construit que lorsqu’il existe une hypothèse raisonnable d’amélioration. Il sera évalué comme n’importe quelle autre piste et pourra parfaitement se révéler inutile, trop complexe ou moins intéressant qu’une solution plus simple. Le but n’est pas de faire gagner le prototype, ni de prouver que l’IA ou un nouvel outil ferait mieux.
Au fil des expérimentations, je distinguerai également ce qui relève encore d’une hypothèse. Je préciserai ce que j’ai effectivement testé dans le laboratoire. Et, lorsque l’occasion se présentera, ce qui aura pu être confronté aux conditions réelles d’une agence.
Les premiers sujets que je vais explorer
Je vais commencer par un domaine très concret : les appels d’offres de maîtrise d’œuvre.
Trois questions serviront de premiers terrains d’expérimentation :
- comment repérer les consultations réellement adaptées à une petite agence sans passer des heures à chercher et à trier
- comment analyser un appel d’offres et préparer une candidature sans y consacrer un temps disproportionné
- comment savoir si le temps investi dans une candidature (puis plus largement dans une mission) reste économiquement raisonnable
Je ne sais pas encore quelles solutions sortiront de ces 3 tests. C’est précisément ce que je veux découvrir.
Que deviennent mes premières recherches pour l’outil global ?
Pour préparer le premier projet, j’avais imaginé une petite agence fictive et commencé à décortiquer son fonctionnement. Les demandes arrivent, les projets, les intervenants, les consultations, les marchés, les visites de chantier, les observations, la réception ou encore le SAV.
Ce travail m’a permis de faire émerger plusieurs situations qui pourraient poser problème dans une petite agence :
- une information dispersée entre plusieurs supports
- une action dont la prochaine étape n’est pas claire
- une observation de chantier difficile à suivre jusqu’à sa résolution
- une donnée ressaisie plusieurs fois
- une échéance qui dépend encore beaucoup de la mémoire de chacun.
Mais ce ne sont pour l’instant que des hypothèses.
Je vais donc conserver ce travail comme une réserve de pistes à tester, sans considérer qu’elles correspondent automatiquement aux difficultés réelles des agences.
Selon les sujets, les expérimentations pourront s’appuyer sur :
- des résultats d’études publiques
- des situations issues de mon expérience professionnelle
- des cas reconstitués
- les signaux repérés dans ma veille
- lorsque ce sera possible, des situations provenant de vraies agences.
L’important sera de toujours préciser sur quoi repose le test et ce qu’il permet réellement de conclure.
Et maintenant ?
La première expérimentation partira d’une question très concrète :
Comment repérer les appels d’offres de maîtrise d’œuvre réellement adaptés à une petite agence sans passer des heures à chercher et à trier ?
Je commencerai par observer ce que demande une recherche de référence et par identifier les pistes qui pourraient réellement réduire le temps de recherche et surtout le volume de consultations inutiles à trier.
Les services publics, fonctions gratuites ou autres solutions accessibles sans dépense spécifique pourront être testés lorsqu’ils paraissent pertinents. Les solutions payantes pourront être identifiées et documentées, mais je ne souscrirai pas à un abonnement uniquement pour les besoins de l’expérimentation.
Si, après cette première exploration, une amélioration semble possible, je pourrai également construire un prototype dans le laboratoire.
Les pistes réellement testées seront évaluées notamment sur :
- le temps nécessaire
- la pertinence des consultations trouvées
- les annonces manquées
- les faux positifs
- la facilité de tri
- le coût
- la complexité.
Je ne sais donc pas encore jusqu’où ira cette première expérimentation, ni même si elle nécessitera de construire quelque chose. C’est justement ce que le test doit permettre de déterminer.
Alors, à très vite pour le bilan de la première expérimentation !
Vous voulez suivre les expérimentations ?
Laissez votre prénom et votre email et je vous préviendrai dès la publication du prochain test.
Article rédigé par Sandrine Benoit