Ou comment j’ai démarré la semaine 1 de mon défi par la sélection des données essentielles du Cabinet d’architecture fictif grâce à l’IA.
Dans l’article précédent, que vous pouvez consulter ici, je vous présentais le défi que je me suis lancé : construire, sur une période de 52 semaines, un outil de gestion complet pour un cabinet d’architecture fictif, en m’appuyant notamment sur ChatGPT comme support d’analyse.
Cette semaine, j’aurais donc pu commencer directement par créer ma première base de données. Mais avant de créer ou d’automatiser quoi que ce soit, encore faut-il savoir précisément ce que l’on veut suivre (quelles données) et comment toutes ces informations sont liées entre elles.
Imaginez un lundi matin dans une petite agence …
… un prospect demande un rendez-vous, une entreprise répond à une Observation de chantier, un maître d’ouvrage signale un problème après la Réception, un fournisseur relance une facture et une candidature arrive dans la même boîte mail.
Ces situations n’ont rien à voir entre elles. Pourtant, elles arrivent souvent par les mêmes portes : emails, téléphone ou formulaire de votre site internet.
Vous enregistrez ensuite ces informations dans vos dossiers, tableaux, comptes rendus, agenda … ou parfois uniquement la mémoire de celui ou celle qui suit le sujet.
J’ai bien connu ce fonctionnement pendant mes quatorze années d’exercice comme architecte libérale. En petite équipe, il peut fonctionner longtemps. Mais plus le nombre de Projets augmente et plus les années passent, et cette organisation se fragilise.
C’est donc par là que j’ai commencé …
… identifier les informations qui entrent dans le cabinet et celles qu’il faut ensuite suivre.
Dès cette première étape, j’ai utilisé ChatGPT comme partenaire d’analyse pour décortiquer le fonctionnement du cabinet, repérer les liens et faire apparaître les incohérences possibles.
J’ai ensuite complété, corrigé ou écarté ses propositions lorsqu’elles ne correspondaient pas à la réalité du métier.
À la fin de cette première semaine, je n’ai donc pas commencer à construire l’outil, mais j’ai mis en place la colonne vertébrale du futur système.
Pourquoi n’ai-je pas commencé directement par construire la base de données ?
J’aurais pu commencer immédiatement à créer des tables : « Clients », « Projets », « Chantiers », « Entreprises » … Cela aurait donné rapidement quelque chose de concret à vous montrer, mais aurait aussi figé des choix avant même d’avoir vérifié s’ils correspondaient réellement au fonctionnement d’un cabinet d’architecture.
Une base de données bien remplie peut quand même reproduire une mauvaise organisation
Regrouper des informations dans une base de données ne rend pas automatiquement l’organisation plus cohérente.
Si une information est enregistrée à plusieurs endroits, on peut reproduire le même doublon dans plusieurs tables. Si le chantier est géré comme un dossier séparé du Projet, on peut aussi recréer cette rupture dans le futur système.
Il faudrait alors revoir plus tard les tables et leurs liens : des allers-retours inutiles et une perte de temps.
C’est précisément ce que je voulais éviter.
J’ai donc utilisé l’IA avant de construire une base de données
Plutôt que de demander directement à ChatGPT de me créer une base de données, je l’ai utilisé pour questionner l’organisation du cabinet. Nous avons passé en revue les différentes étapes et les informations nécessaires. Par exemple :
- que devient une Demande entrante lorsqu’elle arrive au cabinet ?
- faut-il distinguer une Opportunité commerciale d’une Proposition, un Contrat d’un Projet ?
- comment suivre une entreprise qui intervient sur plusieurs Lots ?
- que devient une Observation faite pendant une Visite de chantier ?
- comment conserver le lien entre la Réception, les Réserves, les garanties et le SAV ?
ChatGPT m’a aidée à explorer les possibilités, à repérer des incohérences et à faire émerger de nouvelles questions. Mon expérience du métier m’a ensuite permis de vérifier, corriger et trancher lorsque ses propositions ne correspondaient pas à la réalité d’une agence.
Cette première étape devait donc décrire le métier avant de décrire la base. Le résultat est une carte structurée de ce que le futur système devra suivre et des règles qu’il devra respecter avant de commencer à construire.
Qu’ai-je réellement construit pendant cette première semaine ?
Le travail d’analyse m’a permis d’identifier 36 Objets métier et 42 règles de cohérence qui serviront de fondations au futur système. Dit comme cela, cela peut paraître assez lourd.
Un Objet métier, c’est simplement une information importante que le cabinet doit pouvoir suivre séparément : une Organisation (le terme que j’utilise pour désigner de façon générale une entreprise, une société, un organisme ou un particulier), une Demande entrante, un Projet, une Visite, une Observation, un Marché, une Réserve, une Échéance…
Cela ne signifie pas qu’il y aura forcément 36 tables : il faudra encore décider comment organiser techniquement ces informations dans la base de données.
Les 42 règles de cohérence servent, elles, à éviter que le futur système produise des situations qui ne correspondent pas au fonctionnement du cabinet.
Par exemple :
- si une entreprise a plusieurs Lots sur un même Projet, elle a un Marché distinct pour chacun d’eux
- une même Organisation ne doit pas être recréée plusieurs fois simplement parce qu’elle joue plusieurs rôles
- une action sensible ne devra pas être validée automatiquement par l’IA
- …
Sept grandes familles d’informations
Pour y voir plus clair, j’ai regroupé les 36 Objets métier en 7 grandes familles :
- les Organisations, Contacts et Demandes entrantes
- le cycle commercial, depuis l’Opportunité jusqu’au Contrat signé
- les Projets, avec leurs phases, intervenants, tâches et Échéances
- les consultations et les Marchés des entreprises
- le suivi du chantier, avec les Visites, Observations et comptes rendus
- la Réception et l’après-chantier, avec les Réserves, garanties et demandes SAV
- la gestion interne du cabinet, avec notamment ses réunions, engagements et Échéances.
L’objectif n’est pas de tout faire entrer de force dans un seul logiciel, mais de conserver les liens entre toutes ces informations.
Une Demande entrante peut devenir une Opportunité, puis un Projet, donner lieu à un chantier et parfois revenir plusieurs années plus tard sous la forme d’une demande SAV. Si ces étapes sont pensées séparément dès le départ, il sera beaucoup plus difficile de les relier ensuite.
Cinq décisions structurantes
1. Une Demande entrante qui ne se limite pas aux prospects
La première décision a été de ne pas considérer que toute Demande entrante était forcément commerciale. Dans un cabinet d’architecture, elles sont beaucoup plus variées et ne relèvent pas toutes d’une logique de prospect. Un email ou un appel peut concerner :
- un nouveau Projet potentiel
- un Projet déjà en cours
- une demande après Réception ou en SAV
- une facture ou un paiement fournisseur
- une candidature
- une entreprise ou un prestataire qui contacte le cabinet
- un sujet lié au fonctionnement interne de l’agence
- ou simplement un message qui ne nécessite aucune suite.
J’ai donc choisi de créer une porte d’entrée commune :
La Demande entrante, c’est toute sollicitation reçue par le cabinet, quelle qu’en soit la nature.
À son arrivée, la Demande entrante pourra être identifiée, qualifiée puis orientée vers le bon processus.
Plus tard, l’IA pourra analyser la nature d’une Demande entrante, en extraire des informations utiles ou suggérer à quel dossier elle semble correspondre. Mais elle ne décidera pas seule du traitement lorsque les conséquences peuvent être importantes.
L’objectif est simple : ne pas perdre une information simplement parce qu’elle n’entre pas dans la case « prospect ».
2. Un Projet qui reste le fil conducteur, du Contrat jusqu’au SAV
La deuxième décision a été de ne pas séparer artificiellement le Projet et le chantier.
Dans la pratique, il peut être tentant de créer un dossier « Projet » pour les premières phases, puis un dossier « Chantier » lorsque les travaux commencent.
Mais on parle toujours de la même opération.
Le chantier est donc traité comme une étape du Projet, avec ses propres informations : entreprises, Lots, Marchés, Visites, Observations, comptes rendus, puis Réception.
Cela permet de conserver un fil continu entre les différentes étapes :
Demande entrante → Opportunité → Proposition → Contrat → Projet → chantier → Réception → garanties et SAV.
Cette continuité est particulièrement importante dans le temps. Quelques années après la fin des travaux, si un maître d’ouvrage revient vers l’agence pour un problème en SAV, il doit être possible de retrouver facilement le Projet concerné, les entreprises intervenues, les Marchés, les Observations de chantier, la Réception et les éventuelles Réserves.
L’objectif est d’éviter plusieurs dossiers parallèles qui finiraient par raconter chacun une partie différente de la même histoire.
Le Projet reste le point de référence autour duquel viennent se rattacher les différentes étapes de la mission.
3. Une Organisation unique qui peut avoir plusieurs rôles
La troisième décision concerne la manière de gérer les personnes et les structures avec lesquelles le cabinet travaille.
Comme je l’expliquais plus haut, j’utilise le terme Organisation pour regrouper sous une même dénomination les différents types de tiers avec lesquels le cabinet est en relation.
Il aurait été assez naturel de créer plusieurs catégories séparées, (clients, entreprises de travaux, fournisseurs, partenaires, …) mais une même structure peut avoir plusieurs rôles au fil du temps.
Une entreprise peut intervenir sur un chantier, devenir fournisseur du cabinet puis être sollicitée sur une autre opération. Créer une nouvelle fiche à chaque rôle risquerait de dupliquer les mêmes coordonnées et de créer des informations contradictoires.
J’ai donc retenu une seule dénomination : Organisation, à laquelle peuvent être associés un ou plusieurs rôles.
Les personnes physiques avec lesquelles le cabinet échange seront rattachées à cette Organisation en tant que Contacts. Un particulier pourra lui aussi être enregistré selon la même logique.
L’objectif est simple :
Une même réalité ne doit être enregistrée qu’une seule fois, puis utilisée dans différents contextes.
Cela évitera les doublons et facilitera la recherche d’informations, les mises à jour et le suivi de l’historique.
4. Des données structurées avant les comptes rendus et les courriers
Prenons un exemple très concret : une Observation faite pendant une Visite de chantier.
Aujourd’hui, cette Observation peut être notée pendant la Visite, puis reprise dans un compte rendu envoyé en PDF aux différents intervenants.
Le document permet de formaliser ce qui a été constaté et de transmettre l’information. Mais si cette Observation n’existe que dans le PDF, il devient beaucoup plus difficile de l’exploiter ensuite.
Comment retrouver rapidement toutes les Observations encore en attente ? Lesquelles concernent une entreprise précise ? Lesquelles ont une Échéance dépassée ? Lesquelles doivent encore être vérifiées lors de la prochaine Visite ?
Pour répondre facilement à ces questions, l’Observation doit d’abord exister comme donnée structurée, reliée par exemple au Projet, au Lot, à l’Organisation responsable, à une Échéance et à un statut.
Le compte rendu pourra ensuite être produit à partir de ces informations, puis relu et validé avant son envoi.
Cette logique va bien au-delà du chantier : toute information que vous souhaitez retrouver, filtrer, affecter, suivre dans le temps ou utiliser plus tard doit pouvoir être enregistrée sous une forme exploitable par le système.
La donnée sert donc au suivi et au pilotage
Le document sert à formaliser et à communiquer.
L’un ne remplace pas l’autre. Ils n’ont simplement pas le même rôle.
5. Un Marché distinct pour chaque Lot
La cinquième décision concerne le suivi des entreprises pendant le chantier.
Une même entreprise peut intervenir sur plusieurs Lots d’un même Projet.
Par exemple, elle peut être titulaire à la fois du Lot « plâtrerie » et du Lot « peinture ».
Il aurait été possible de créer un seul Marché pour cette entreprise. Mais chaque Lot a son propre montant, ses avenants, son avancement, ses situations de travaux et, éventuellement, ses pénalités.
J’ai donc retenu une règle simple qui est généralement le plus communément suivie :
Un Marché correspond à un seul Lot.
Si une entreprise obtient trois Lots sur le même Projet, elle aura donc trois Marchés distincts.
Cette distinction permettra de savoir où en est chaque Lot sans mélanger les informations financières ou l’avancement de prestations différentes. C’est un bon exemple d’un choix simple à faire ou à corriger maintenant, mais beaucoup plus compliqué une fois le système construit.
Que pouvez-vous en retenir dès aujourd’hui ?
Même sans construire un outil complet, cette première semaine fait ressortir quelques questions que vous pourriez déjà vous poser.
Où se trouve votre information de référence ?
Si une adresse, une Échéance, un montant ou le nom d’un intervenant est enregistré à plusieurs endroits, il y a toujours un risque qu’une version soit mise à jour et qu’une autre ne le soit pas.
L’idéal est d’identifier une seule source de référence pour chaque information importante, puis de la réutiliser dans différentes tables de la base de données, dans différents documents ou vues.
Chaque sujet en cours a-t-il un responsable et une prochaine action ?
Une Demande entrante, une Observation, une Échéance ou une tâche ne devrait pas rester « quelque part dans le dossier » sans que vous sachiez clairement qui doit agir et quelle est la prochaine étape.
Cette règle simple évite beaucoup de sujets oubliés ou reportés indéfiniment.
Vos informations restent-elles reliées dans le temps ?
Une Demande entrante peut devenir une Opportunité, puis un Projet, donner lieu à un chantier, à une Réception, et parfois revenir plus tard sous la forme d’une demande SAV.
Si ces étapes sont gérées séparément, retrouver l’historique devient vite compliqué.
La vraie question à vous poser est donc moins :
« Est-ce que j’ai un outil pour chaque besoin ?«
que :
« Est-ce que je peux suivre facilement l’histoire complète d’un sujet, du début jusqu’à sa clôture ?«
C’est l’un des enseignements importants de cette première semaine.
Quelle place ai-je prévue pour l’IA ?
À ce stade, aucune fonction d’IA n’est encore intégrée au futur outil. Cette première semaine m’a néanmoins permis de définir où elle pourrait être utile et où elle ne devra pas décider seule.
L’IA pour préparer, classer et analyser
Une fois les informations du cabinet mieux structurées, l’IA pourra intervenir sur des tâches où elle apporte un vrai gain de temps.
Elle pourra par exemple :
- proposer une qualification pour une Demande entrante
- extraire des informations utiles à partir d’un email ou d’un document
- résumer l’historique d’un Projet
- remettre en forme des informations saisies de manière différente
- comparer plusieurs offres d’entreprises et faire ressortir les écarts, oublis ou variantes
- préparer un premier brouillon de réponse ou de document.
Dans tous ces cas, l’IA ne remplace pas votre expertise. Elle vous aide à préparer l’information, la rendre plus lisible ou attirer votre attention sur certains points.
Certaines décisions doivent rester humaines
D’autres actions ont des conséquences trop importantes pour être confiées automatiquement à l’IA.
Elle ne devra donc pas, seule :
- attribuer un Marché à une entreprise
- reconnaître une responsabilité
- valider un paiement
- lever une Réserve
- clôturer un dossier sensible …
Dans ces situations, l’IA pourra préparer l’analyse ou rassembler les informations utiles, mais la décision restera humaine.
L’IA prépare, vous vérifiez.
L’IA propose, vous décidez.
L’IA reformule, vous validez.
C’est la place que je veux lui donner dans ce projet : celle d’un assistant capable de vous faire gagner du temps dans l’analyse et la préparation, sans se substituer à votre jugement professionnel.
Qu’est-ce qui n’est pas encore construit ?
À ce stade, le futur outil n’existe encore que sous la forme d’une structure métier. Je n’ai pas encore construit la base de données, les écrans, les automatisations, les connexions avec d’autres services ni les fonctions utilisant l’IA. Et c’est volontaire.
Cette première semaine devait répondre à une question préalable : quelles informations le système doit-il réellement suivre et quelles règles doit-il respecter ?
Maintenant, avant de commencer à construire, il reste une autre décision importante à prendre : avec quels outils vais-je le faire ?
Je vais donc utiliser ChatGPT pour m’aider à définir les critères de choix et comparer les solutions possibles. Simplicité d’utilisation, capacité à faire évoluer le système, connexions avec d’autres services, coût, hébergement des données ou utilisation sur ordinateur, tablette et smartphone feront notamment partie des critères à étudier. Le choix final restera le mien, en fonction des besoins du cabinet fictif et des contraintes du projet.
Ce que cette première semaine m’a appris
Cette première semaine m’a surtout rappelé une chose : commencer par construire n’est pas forcément commencer par avancer.
J’aurais pu ouvrir directement un outil de base de données et créer quelques tables, avec rapidement quelque chose de visible à vous montrer. Mais j’aurais aussi pris le risque de construire sur de mauvaises bases.
Le travail avec ChatGPT m’a obligée à revenir au fonctionnement réel du cabinet. Ce questionnement m’a permis de repérer plusieurs pièges avant même de commencer à construire : séparer inutilement Projet et chantier, dupliquer les Organisations selon leurs rôles, enfermer des actions dans des documents ou suivre plusieurs Lots dans un seul Marché.
L’enseignement que j’en retiens est simple :
Avant d’automatiser, il faut d’abord comprendre ce que l’on veut réellement organiser.
Et parfois, la première semaine la plus utile est justement celle où l’on ne construit encore rien.
Prochaine étape : choisir les bons outils avant de construire
Cette première semaine m’a permis de définir ce que le futur système devra gérer. La prochaine question est très concrète :
Avec quels outils vais-je pouvoir le construire ?
Pendant la semaine 02, je vais repartir des besoins identifiés ici et utiliser ChatGPT pour comparer les solutions possibles : base de données, interface utilisateur, automatisations, IA, messagerie, documents…
Je veux comprendre quel rôle chaque outil devra réellement jouer dans le système, ce qu’il apporte et quelles contraintes il impose.
L’objectif de la semaine 02 ne sera donc pas encore de construire, mais de choisir une architecture d’outils suffisamment simple pour démarrer et suffisamment évolutive pour accompagner les 50 semaines suivantes du défi.
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