Nous sommes en 2026. Nous avons des outils IA capables de générer des user stories à partir d'une transcription de réunion en quelques secondes. Nous avons des copilots qui écrivent du code.
Le Requirements Engineering devrait donc être un problème résolu maintenant, non ?
Eh bien, pas tout à fait.
Les outils se sont améliorés. Beaucoup améliorés. Mais le défi central reste le même, surtout lorsqu'on regarde du côté des petites et moyennes entreprises.
L'IA est votre turbo, pas votre conducteur
Oui, nous utilisons l'IA. Tous les jours.
Avant, le Requirements Engineering ressemblait à cela : atelier de deux heures, puis trois heures pour trier les notes, les structurer et rédiger les tickets.
Aujourd'hui : on injecte la transcription, on demande "résume les points clés pour le système de tickets", et c'est fait en cinq minutes.
C'est brillant. Cela nous enlève le travail ingrat. Nous pouvons extraire de la documentation d'un legacy code bien plus vite ou générer de premiers brouillons de diagrammes de processus.
Mais : l'IA ne comprend pas réellement le contexte.
Elle ne sait pas que Monsieur Müller à l'entrepôt utilise un workaround spécial depuis 20 ans parce que l'ancien ERP plante sur les caractères spéciaux. Elle ne voit que le processus "officiel".
L'IA vous aide à documenter plus vite et à détecter des lacunes, "il manque une condition pour le cas d'erreur". Mais elle ne remplace pas la conversation. Elle la rend simplement plus efficace, parce que vous pouvez vous concentrer sur le contenu au lieu de taper du texte.
Le problème du monopole de connaissance, spécial PME
Dans les petites et moyennes entreprises, nous rencontrons souvent un phénomène que même la meilleure IA ne peut pas résoudre : le monopole de connaissance.
Il y a toujours ce collaborateur, appelons-le Klaus, qui sait tout.
- Comment calcule-t-on les prix spéciaux pour les comptes clés ? Demandez à Klaus.
- Que se passe-t-il avec un retour de l'étranger sans bon de livraison ? Klaus le sait.
- Pourquoi fait-on cela de cette manière ? "Parce que Klaus l'a toujours fait comme ça."
Quand vous construisez un logiciel pour une entreprise de ce type, votre travail ne consiste pas seulement à écrire des exigences. Votre travail consiste à rendre accessible cette connaissance distribuée.
C'est souvent pénible. Pour Klaus, parce qu'il doit lâcher prise et partager sa connaissance exclusive. Et pour vous, parce que cette connaissance est souvent non structurée, contradictoire et écrite nulle part.
C'est là que les projets échouent souvent : non pas à cause de la technologie, mais parce que personne n'ose remettre en question les processus de Klaus ou les numériser réellement. Aucune IA ne peut défaire ce nœud humain. Vous devez le faire vous-même, avec empathie et patience.
La technologie change, la communication reste
Que nous utilisions Waterfall, Agile, Scrum ou "AI-Driven Development", au final, ce sont toujours des humains qui construisent des logiciels pour d'autres humains.
Les outils de 2026 nous aident à construire des prototypes plus vite, "tiens, clique dedans, est-ce que c'est bien ce que tu voulais ?". C'est un énorme avantage par rapport au passé, où nous passions des semaines à discuter de concepts de manière abstraite. Nous pouvons montrer les choses au lieu de simplement les décrire.
Mais la compréhension du pourquoi, pourquoi faisons-nous cela ? Quel problème résolvons-nous ?, cela doit toujours émerger entre les personnes.
Aucune IA ne vous dira : "En fait, cette fonctionnalité n'est pas nécessaire si on réorganise simplement le processus dans l'entrepôt."
Voilà pour notre petite série sur le Requirements Engineering.
Depuis la vertical slice, réduction du risque technique, en passant par le cycle itératif, apprendre au lieu de deviner, jusqu'à la réalité des PME avec les monopoles de connaissance.
Nous espérons que vous y avez trouvé quelques idées utiles pour votre prochain projet.
Besoin d'aide ?
Monopoles de connaissance, processus flous, ou tout simplement pas de temps pour le Requirements Engineering ? Nous vous aidons à remettre de la structure, de la première analyse jusqu'au système opérationnel. Contactez-nous.
