Pourquoi les devs et consultants ESN perdent-ils autant de temps sur la doc technique ?
Parce que la doc technique n'a jamais un seul endroit : elle est répartie entre des espaces Confluence par client, des PDF normatifs, des conventions internes et la mémoire de deux ou trois personnes seniors. Le Stack Overflow Developer Survey 2024 mesure que 61 % des développeurs passent plus d'une demi-heure chaque jour à chercher une réponse à une question technique. Sur une équipe de dix consultants, ça fait plusieurs heures perdues chaque jour, facturées ou non selon le contrat.
Une étude 2025 sur les frictions organisationnelles dans les équipes de développement va plus loin : elle montre que 90 % des développeurs gaspillent six heures ou plus par semaine à cause de blocages d'accès à l'information, malgré l'arrivée des outils IA génériques dans leur quotidien. Un assistant en langage courant, ChatGPT ou Copilot ouvert à côté, ne sert à rien s'il ne connaît pas vos référentiels de projet, votre wiki Confluence ou vos conventions internes.
Comment un assistant IA interroge concrètement votre doc technique et vos référentiels ?
Le principe : connecter l'assistant à vos sources réelles (Confluence, PDF normatifs, wikis projet) plutôt que lui demander de deviner. Sur la démonstration bcome, la source de référence est le Référentiel général d'écoconception des services numériques (RGESN) v1.0.1, publié par la mission numérique écoresponsable de l'État. Un dev pose sa question comme il la poserait à un collègue senior : « quel critère RGESN s'applique à une image non compressée sur une page produit ? ». L'assistant retrouve le passage exact du référentiel, cite le numéro de critère et le lien vers le PDF source, sans reformuler la règle de façon approximative.
Le même mécanisme s'applique à un espace Confluence de projet ou à un ensemble de PDF normatifs internes : l'assistant lit les documents que vous lui connectez, et répond en citant lequel dit quoi, avec le passage précis. Aucune règle inventée, aucune réponse sans source consultable et vérifiable en un clic.
Quelles sources peut-on connecter : Confluence, wikis projet, PDF normatifs ?
Toutes celles qui existent déjà dans une ESN ou une agence digitale : espaces Confluence par client ou par projet, PDF de référentiels (RGESN, RGAA, guides internes de codage), wikis Notion, comptes-rendus d'architecture, tickets Jira archivés. L'assistant lit ce que ces outils contiennent déjà et y répond directement, sans qu'un dev les rouvre un par un.
Ce point rejoint un problème plus large : un assistant IA générique repart de zéro à chaque conversation, sans mémoire de ce qu'une équipe a documenté ou décidé. On détaille ce mécanisme dans Vos agents IA n'ont pas de mémoire : donner à un assistant l'accès à une base de connaissances écrite change ce qu'il peut réellement répondre, projet après projet.
Quelles sont les limites d'un assistant IA sur la doc technique interne ?
Un assistant connecté à vos référentiels retrouve la règle et la source. La décision d'architecture reste au lead dev, et la conformité d'une livraison client reste validée par le responsable technique du projet. Sur un point réglementaire ou contractuel sensible, la réponse de l'assistant sert de point de départ documenté à vérifier avant de trancher.
Autre limite réelle : la qualité de la réponse dépend de la qualité de ce qui est connecté. Un wiki Confluence resté en friche depuis deux ans donnera une réponse sourcée mais datée, donc fausse dans les faits. Le premier travail, souvent fait pendant le cadrage, consiste à identifier quelles sources sont encore fiables avant de les rendre interrogeables, et à écarter celles qui ne le sont plus.
Dernier point à cadrer avant tout déploiement : qui peut poser quelle question. Un junior en mission chez un client A ne doit pas retrouver, via l'assistant, une convention ou un choix d'architecture confidentiel d'un client B. Ce cloisonnement par projet ou par client se paramètre en amont, en même temps que le choix des sources à connecter.
Pourquoi ce sujet compte particulièrement pour une ESN ou une agence digitale ?
Le temps qu'un consultant passe à chercher une réponse au lieu de coder est rarement facturable au client. Il pèse directement sur la marge du projet, encore plus quand l'équipe tourne vite entre missions et que chaque nouveau consultant redécouvre les mêmes conventions. Un référentiel comme le RGESN illustre bien le problème : de plus en plus de cahiers des charges publics ou grands comptes l'exigent, mais peu d'équipes techniques le maîtrisent au point de citer le bon critère de mémoire.
Rendre ce type de référentiel interrogeable, avec vos propres wikis projet à côté, réduit le temps perdu par consultant et limite le risque qu'une règle importante soit oubliée entre deux projets qui se ressemblent sans être identiques.
Combien de temps pour déployer une base de connaissances technique interne dans une ESN ou une agence digitale ?
Un périmètre resserré (un référentiel comme le RGESN, un espace Confluence, quelques PDF internes) se met en place en quelques semaines : connexion des sources, tests avec deux ou trois devs sur leurs vraies questions, ajustements des réponses imprécises, puis ouverture à l'équipe. La suite consiste à élargir le périmètre projet par projet plutôt que de tout connecter d'un coup, pour garder une base fiable et à jour.
Pour les ESN et agences digitales qui veulent chiffrer précisément ce gain sur leur propre documentation avant de s'engager, voir les autres cas d'usage IA pour ESN et agences digitales.
