Une analyse par les contraintes, la maîtrise et les niveaux de décision.

1. Introduction : une illusion contemporaine

Dans la pratique de l'ingénierie comme du design, il est évident que l'on ne conçoit jamais un objet dans son intégralité. Un produit industriel intègre des composants standardisés : vis, connecteurs, protocoles, bibliothèques logicielles. Il serait absurde de redessiner une vis à chaque projet. Pourtant, personne ne conteste que l'ingénieur qui choisit une vis M4 plutôt qu'une M5 réalise un acte de conception.

De même, un développeur reste un concepteur quand il utilise une librairie existante ou un module de paiement prêt à connecter à son application. Il ne conçoit pas tout, mais il conçoit bien quelque chose : l'intégration, l'architecture, les arbitrages, les dépendances.

Savoir où commence et où s'arrête son propre périmètre de conception est déjà un défi quotidien pour tout concepteur. L'IA ne fait que rendre cette question plus fréquente et plus difficile à trancher.

Cette observation apparemment triviale devient en effet problématique dans le contexte actuel des outils génératifs. Lorsqu'un système d'intelligence artificielle produit un modèle 3D complet, une interface ou une application fonctionnelle à partir d'une simple description, la question se pose différemment : s'agit-il encore de conception, ou d'une forme d'assemblage de solutions préexistantes « sur-étagère » ou « on-demand », masquée par la puissance de génération ?

C'est la même question que l'on retrouve derrière des débats très concrets : les personnes qui font du vibe coding conçoivent-elles réellement ? Produisent-elles des choses utiles ? Ou fabriquent-elles surtout des systèmes fragiles, non maintenables, voire dangereux ?

Autrement dit, si l'on admet que l'on ne conçoit jamais tout, où se situe la limite entre concevoir, assembler, déléguer et utiliser une solution sur étagère ?

2. Définition : concevoir, c'est résoudre des contraintes

Pour répondre à cette question, il est nécessaire de préciser ce que l'on entend par « concevoir ». Je propose de partir d'une définition opératoire :

Concevoir consiste à résoudre un ensemble de contraintes pour atteindre une intention donnée.

Cette définition repose sur trois éléments indissociables : une intention, des contraintes et une résolution.

Prenons un exemple simple. Le choix d'une vis dans un assemblage mécanique ne consiste pas à inventer une nouvelle géométrie de filetage, mais à arbitrer entre plusieurs contraintes : encombrement, résistance mécanique, matériau du support, facilité de montage, coût, disponibilité.

Choisir une vis M4 plutôt qu'une M5 revient donc à résoudre ces contraintes dans un contexte donné. L'acte de conception ne réside pas dans la création de la vis elle-même, mais dans la compréhension et l'arbitrage des contraintes qui justifient ce choix.

Cette distinction permet d'introduire une séparation fondamentale entre deux situations.

Dans le premier cas, l'individu comprend les contraintes et la manière dont elles sont résolues. Il peut expliquer son choix, le modifier si les conditions évoluent, et en anticiper les conséquences.

Dans le second cas, il utilise une solution sans comprendre les mécanismes qui la rendent valide. Il peut constater que « cela fonctionne », mais ne peut ni justifier ni adapter la solution de manière fiable.

La première situation relève de la conception. La seconde relève plutôt de l'assemblage ou de l'utilisation.

On peut donc imaginer tout un espace continu de conception, entre tout concevoir, concevoir certains éléments seulement, assembler des solutions existantes, acheter une solution sur étagère, ou simplement utiliser un système déjà constitué.

3. Niveaux de conception : abstraction et granularité

Cette définition doit cependant être complétée par une observation essentielle : la conception ne s'effectue jamais à un niveau unique. Elle se déploie selon au moins deux dimensions distinctes.

La première est le niveau d'abstraction. Elle correspond à la nature des décisions prises. On peut distinguer, de manière simplifiée, plusieurs niveaux de conception : stratégique, fonctionnel, technique et opérationnel.

Dit plus simplement, on ne conçoit pas seulement la partie technique d'un produit. On conçoit aussi sa valeur d'usage, son esthétique, son expérience, son modèle économique, ou sa place dans un système plus large.

La seconde dimension est le niveau de granularité. Elle correspond à l'échelle du système considéré : concevoir un produit complet, un sous-système, un composant, ou un détail. Dans les faits, il est très rare de concevoir 100 % d'un produit.

Ces deux dimensions sont indépendantes. Il est possible de concevoir à un niveau d'abstraction élevé sur un élément très fin, par exemple en définissant le comportement d'un bouton dans une interface. Il est également possible de concevoir à un niveau d'abstraction technique sur un système large, par exemple en définissant l'architecture globale d'une application.

L'exemple d'un collègue non développeur utilisant une IA pour générer une application illustre cette distinction. Cet individu peut définir avec précision les fonctionnalités attendues, les règles d'interaction et les principes du design system. Il opère donc à un niveau d'abstraction élevé. En revanche, il ne maîtrise pas nécessairement la structure du code généré ni les mécanismes techniques sous-jacents.

Il ne conçoit pas la résolution technique des contraintes, mais il conçoit néanmoins leur formulation.

4. La dimension critique : la maîtrise

Au-delà de l'abstraction et de la granularité, une troisième dimension s'avère déterminante : la maîtrise de la résolution des contraintes.

Cette maîtrise ne se réduit pas à une connaissance superficielle. Elle implique la capacité à expliquer pourquoi une solution fonctionne, à la modifier de manière ciblée, et à anticiper les effets d'un changement de contrainte.

C'est cette dimension qui permet de distinguer, de manière rigoureuse, la conception de l'utilisation.

On peut illustrer cette idée par deux situations contrastées dans le domaine logiciel. Dans la première, un développeur implémente une fonction critique en comprenant les structures de données utilisées, les contraintes de performance et les implications en termes de maintenance. Dans la seconde, un utilisateur copie un fragment de code généré par une IA sans en comprendre la logique interne.

Dans les deux cas, un résultat fonctionnel peut être produit. Mais seule la première situation relève pleinement d'une conception maîtrisée.

La seconde peut être utile. Elle peut permettre de tester, de prototyper, d'apprendre. Mais elle ne doit pas être confondue avec une conception robuste.

5. L'espace de conception

En combinant ces trois dimensions — abstraction, granularité et maîtrise — il devient possible de mieux situer les différentes formes de conception.

Certaines configurations correspondent à des formes robustes de conception. Par exemple, une maîtrise forte à un niveau technique et sur un système large caractérise l'ingénierie de systèmes complexes, où l'architecture est pensée de manière cohérente et évolutive.

De même, une maîtrise forte sur des éléments fins correspond à l'expertise technique locale, indispensable à la qualité d'exécution.

D'autres configurations sont plus ambiguës. Une abstraction élevée combinée à une faible maîtrise, par exemple, correspond à des situations où l'on spécifie des fonctionnalités sans comprendre leur implémentation. C'est typiquement le cas d'une utilisation naïve d'outils génératifs, où l'utilisateur formule des intentions mais délègue entièrement la résolution des contraintes.

Enfin, certaines configurations sont clairement risquées, en particulier lorsque la granularité est large et la maîtrise faible. Dans ce cas, un système complet est utilisé sans compréhension de ses mécanismes internes, ce qui crée une dépendance forte et limite toute capacité d'évolution.

L'intérêt de cette grille est qu'elle évite une lecture binaire. Il ne s'agit pas de dire qu'une personne conçoit ou ne conçoit pas. Il s'agit de se demander ce qu'elle conçoit exactement, à quel niveau, sur quel périmètre, et avec quel degré de maîtrise.

6. L'effet de l'intelligence artificielle

L'émergence des outils d'intelligence artificielle générative modifie profondément la répartition des activités de conception dans cet espace.

Traditionnellement, produire un système impliquait souvent d'en comprendre les mécanismes. La production et la compréhension étaient étroitement liées. L'IA introduit une dissociation : il devient possible de produire des résultats complexes à partir d'instructions de haut niveau, sans maîtriser les niveaux techniques sous-jacents.

Ce déplacement a deux conséquences majeures.

Premièrement, il permet à des individus non spécialisés d'intervenir à des niveaux d'abstraction élevés. Ils peuvent définir des intentions, formuler des contraintes, produire des prototypes et obtenir des résultats concrets rapidement.

Deuxièmement, il crée une illusion de conception. Le fait de produire un artefact peut être confondu avec la capacité à en maîtriser la logique interne.

Or, comme nous l'avons vu, la conception ne réside pas seulement dans la production du résultat, mais dans la compréhension de la résolution des contraintes.

L'IA ne supprime donc pas la conception. Elle rend simplement plus floue la frontière entre formulation, production, délégation et maîtrise.

7. Le cas du vibe coding

Le vibe coding illustre parfaitement cette ambiguïté.

D'un côté, il serait trop facile de le réduire à une pratique amateur produisant nécessairement de mauvais systèmes. Dans certains cas, il permet de prototyper rapidement, de tester un besoin, de matérialiser une idée, ou de créer un outil interne utile.

Il peut même améliorer la formulation du besoin, car il permet à la personne qui vit réellement la contrainte de produire une première réponse concrète.

Un opérateur qui automatise un processus interne comprend souvent mieux que quiconque les contraintes opérationnelles. Un profil business qui construit une première version d'un produit peut tester rapidement une proposition de valeur. Un designer qui génère une interface interactive peut explorer plus vite des scénarios d'usage.

Dans ces cas, il y a bien conception. Mais elle est située au niveau de l'intention, des usages, des règles métier ou de l'exploration fonctionnelle.

D'un autre côté, il serait naïf de considérer que cette production rapide suffit toujours.

Le problème commence lorsque le prototype devient produit sans changement de régime. Lorsque le code généré devient infrastructure. Lorsque l'automatisation locale devient dépendance critique. Lorsque l'outil bricolé devient indispensable à une équipe sans que personne ne maîtrise réellement son fonctionnement.

Le vibe coding n'est donc pas mauvais en soi. Il devient problématique lorsque la faible maîtrise technique reste invisible ou lorsqu'elle n'est jamais compensée.

La question n'est donc pas de savoir si les gens qui font du vibe coding « font de la m***e ». La question est de savoir dans quelles conditions une production rapide et faiblement maîtrisée doit être transformée en conception maîtrisée.

8. Évolution des profils de concepteurs

La conception ne dépend donc pas d'un métier en tant que tel, mais de la position occupée dans l'espace formé par l'abstraction, la granularité et la maîtrise.

Les rôles historiques de concepteurs professionnels — ingénieur, designer, développeur, architecte — peuvent être relus comme des zones de maîtrise privilégiées plutôt que comme des catégories fixes.

Traditionnellement, ces métiers se répartissaient de manière relativement stable. Les ingénieurs intervenaient principalement à des niveaux d'abstraction technique, avec une forte maîtrise des mécanismes de résolution. Les designers opéraient à des niveaux d'abstraction plus élevés, en structurant les usages, les interactions ou les perceptions. Les architectes, qu'ils soient techniques ou produit, occupaient une position particulière en articulant plusieurs niveaux d'abstraction et en conservant une maîtrise globale des arbitrages.

Cette répartition reposait implicitement sur une contrainte forte : produire impliquait comprendre.

L'émergence des outils génératifs modifie cet équilibre. Elle permet à des profils non techniques — métiers, business, marketing, opérations — de produire directement des artefacts : applications internes, automatisations, interfaces, modèles 3D imprimables, contenus structurés.

Ces profils n'acquièrent pas nécessairement une maîtrise technique équivalente, mais ils accèdent à la capacité de mise en œuvre.

Il apparaît alors une nouvelle catégorie de concepteurs que l'on peut qualifier de concepteurs situés : des individus qui possèdent une maîtrise forte des contraintes dans leur domaine, mais une maîtrise faible de leur résolution technique. Et cela peut avoir un réel intérêt.

Un opérateur qui automatise un processus interne comprend mieux que quiconque les contraintes opérationnelles. Un responsable marketing conçoit des parcours d'acquisition en intégrant des contraintes de perception et de conversion. Un profil business structure une proposition de valeur et un modèle économique.

Dans ces cas, la conception existe pleinement. Mais elle est localisée. Elle porte sur certaines contraintes, non sur l'ensemble de leur résolution.

Cette évolution présente donc un double effet.

D'un côté, elle constitue une opportunité majeure. Les contraintes sont formulées par ceux qui les vivent réellement. La distance entre conception et usage se réduit. Des problèmes auparavant ignorés ou mal traduits peuvent être adressés directement.

De l'autre, elle introduit un risque structurel. La dissociation entre formulation des contraintes et maîtrise de leur résolution peut conduire à une accumulation de solutions fragiles, difficiles à maintenir ou à faire évoluer.

La cohérence globale du système devient alors plus difficile à garantir, car elle n'est plus portée par un nombre limité de profils capables de relier les niveaux.

Ainsi, la transformation des profils ne supprime pas la nécessité de la conception. Elle la redistribue, en créant de nouvelles zones de maîtrise, mais aussi de nouvelles zones de non-maîtrise.

9. La stratégie comme lecture de l'espace de conception

Alors, lequel des deux a raison ? Le profil business qui sort en 24 heures son application sur le marché ou le développeur qui prendra plus de temps, mais produira un système maintenable ?

Pour le savoir, il faut distinguer l'espace de conception lui-même, et la manière dont il est utilisé dans un contexte organisationnel : la stratégie.

Les dimensions d'abstraction, de granularité et de maîtrise décrivent des positions possibles dans cet espace. La stratégie, elle, correspond à l'évaluation de ces positions au regard d'objectifs tels que le coût, la vitesse, la robustesse, la maintenabilité ou la différenciation.

Certaines positions sont adaptées à des objectifs de court terme. Utiliser une solution générée avec une faible maîtrise peut permettre de tester rapidement un marché, d'explorer une idée ou de valider une hypothèse.

D'autres positions sont nécessaires pour construire un avantage compétitif durable. C'est notamment le cas lorsque la solution touche à la sécurité, à la conformité, à l'expérience client critique, à la donnée, ou à un élément différenciant du produit.

La question stratégique n'est donc pas de savoir s'il faut concevoir ou acheter, produire vite ou produire proprement. La vraie question est de déterminer à quel niveau de l'espace de conception il est pertinent de conserver la maîtrise.

10. L'intelligence artificielle comme nouveau sous-traitant

Pour comprendre plus précisément le rôle de l'intelligence artificielle, il est utile de la considérer non pas seulement comme un outil, mais comme un nouvel acteur de la chaîne de conception. Plus précisément, comme une forme particulière de sous-traitance.

Dans un modèle classique, le recours à un sous-traitant implique une délégation partielle de la résolution des contraintes. Une entreprise peut confier la conception d'un module électronique ou le développement d'un logiciel à un prestataire externe. Elle ne maîtrise pas nécessairement les détails de la solution, mais elle s'appuie sur l'expertise du sous-traitant, qu'elle évalue et avec lequel elle établit une relation de confiance.

Ce modèle repose sur plusieurs éléments structurants : la compétence identifiable du prestataire, la possibilité d'échange, la contractualisation des responsabilités, et, dans une certaine mesure, la capacité à auditer ou à challenger les choix effectués.

L'intelligence artificielle générative introduit une forme différente de sous-traitance. Elle produit des solutions à partir d'une description, sans toujours expliciter les mécanismes internes qui ont conduit à ces résultats. Elle ne rend pas compte de ses arbitrages, ne formalise pas ses hypothèses, et ne garantit pas la cohérence de ses décisions dans le temps.

Elle se rapproche ainsi d'un fournisseur de solutions sur étagère dynamiques : des artefacts générés à la demande, adaptés au contexte, mais dont la logique interne reste opaque pour l'utilisateur.

Dans ce cadre, plusieurs conséquences apparaissent.

Premièrement, les barrières à l'entrée diminuent fortement. Là où la réalisation d'un système nécessitait auparavant une expertise spécialisée ou le recours à un prestataire identifié, elle devient accessible via une interaction avec un système génératif.

Deuxièmement, la délégation devient immédiate. Il n'est plus nécessaire de sélectionner un prestataire, de négocier un contrat ou de gérer une relation. Mais cette facilité rend aussi la délégation plus difficile à encadrer. Et c'est là le point critique : la responsabilité de la solution produite reste du côté de l'utilisateur, sans que celui-ci dispose toujours des moyens de l'assumer pleinement.

Troisièmement, la question de la maîtrise se déplace vers une question de confiance. Comme dans le cas d'un sous-traitant humain, l'utilisateur accepte de ne pas comprendre entièrement la solution. Mais à la différence d'un expert identifié, l'IA ne fournit pas de garanties explicites sur la validité de ses choix, ni sur leur adéquation à des contraintes spécifiques.

Cette transformation ne signifie pas la disparition des sous-traitants traditionnels. Au contraire, elle peut renforcer leur rôle dans certains contextes. Lorsque les enjeux de robustesse, de sécurité ou de conformité sont élevés, la nécessité d'une maîtrise explicite redevient centrale.

En ce sens, l'intelligence artificielle ne remplace pas la conception. Elle modifie les conditions dans lesquelles la délégation de conception s'opère.

11. L'IA est-elle alors un outil de conception ?

La catégorisation de la conception en termes d'abstraction, de granularité et de maîtrise peut être étendue aux outils utilisés pour produire les projets.

Il serait toutefois erroné de considérer qu'un outil (de CAO au hasard !) appartient intrinsèquement à une zone donnée de cet espace. Un même logiciel peut soutenir une conception maîtrisée ou, au contraire, favoriser une production sans compréhension, selon la manière dont il est utilisé.

Il est donc plus rigoureux de considérer les outils non comme des catégories fixes, mais comme des vecteurs de déplacement dans l'espace de conception.

Certains outils exposent les contraintes et exigent leur résolution explicite par l'utilisateur. Dans le domaine de la conception mécanique, des logiciels comme SolidWorks ou Fusion 360 imposent de définir des dimensions, des relations géométriques, des matériaux et des conditions de contrainte. Dans le design numérique, des outils comme Figma ou Illustrator structurent la représentation des interfaces ou des formes graphiques sans en automatiser entièrement la logique.

Dans le développement logiciel, des environnements augmentés par l'IA peuvent accélérer l'écriture du code tout en maintenant la responsabilité de la structure et des choix techniques du côté du développeur, à condition d'être utilisés dans cette logique.

D'autres outils reposent au contraire sur une résolution plus implicite des contraintes. L'utilisateur formule une intention, souvent sous forme de texte ou de paramètres globaux, et obtient un résultat fonctionnel ou visuel.

Dans ces situations, l'utilisateur conserve une forme de maîtrise sur l'intention et sur certains paramètres globaux, mais la logique interne de la solution produite reste largement implicite. Les contraintes sont résolues, mais leur résolution n'est pas toujours exposée.

Ces outils sont particulièrement efficaces pour explorer rapidement des variantes, produire des prototypes ou tester des hypothèses. En revanche, ils rendent plus difficile la compréhension fine des choix effectués, ce qui limite la capacité d'adaptation et d'évolution.

Enfin, certains systèmes encapsulent fortement la logique de résolution. Il peut s'agir de services logiciels complexes, de modules propriétaires, de chaînes de traitement automatisées, ou d'agents IA autonomes dont le fonctionnement interne n'est ni visible ni modifiable.

L'utilisation de tels systèmes n'est pas problématique en soi. Elle peut être pertinente pour des fonctions non différenciantes ou des besoins ponctuels. Elle devient critique lorsque ces systèmes occupent une position centrale dans l'architecture globale.

L'enjeu n'est donc pas d'opposer les outils traditionnels et les outils génératifs. Il est de comprendre vers quelles zones de maîtrise ils orientent l'utilisateur.

En synthèse, l'IA est un outil de conception si on l'utilise comme tel. Elle devient un simple générateur de solutions si elle permet de produire sans comprendre. Et elle devient un risque organisationnel lorsqu'elle installe durablement des systèmes opaques sur des zones critiques.

12. Transmission de la conception et dynamiques de collaboration

L'un des effets les plus visibles des outils contemporains, et en particulier de l'intelligence artificielle, est l'effacement partiel des frontières entre les rôles.

Là où les activités étaient historiquement cloisonnées — conception fonctionnelle, design, développement, mise en œuvre — il devient désormais possible pour un individu d'intervenir sur plusieurs niveaux.

Un designer peut produire des interfaces codées, compréhensibles et exploitables par des développeurs. Un développeur peut générer rapidement des interfaces utilisateur ou explorer des logiques d'expérience. Un profil business peut prototyper un produit et le confronter au marché. Un opérateur métier peut construire en quelques jours un outil adapté à ses besoins.

Cette évolution constitue un gain considérable en termes de vitesse d'exploration et de réduction des frictions entre les étapes de conception.

Cependant, cette capacité nouvelle ne résout pas la question de la maîtrise. Elle tend même à la déplacer.

Les artefacts produits dans ces conditions occupent souvent des zones intermédiaires dans l'espace de conception. Ils fonctionnent, mais leur logique interne reste partiellement opaque. Ils répondent à un besoin immédiat, mais leur robustesse, leur évolutivité et leur intégration dans un système plus large ne sont pas garanties.

La question centrale devient alors la suivante : que se passe-t-il après le prototype ?

Le passage d'une solution produite rapidement à une solution conçue de manière durable ne consiste pas simplement à « améliorer » le prototype. Il implique un changement de nature : passer d'une situation où les contraintes sont implicitement résolues par un outil, à une situation où elles sont explicitement comprises et maîtrisées.

Ce passage suppose d'abord une explicitation des contraintes. Un prototype incorpore toujours des hypothèses sur les usages, les cas limites, les performances attendues, les interactions possibles. Tant que ces hypothèses restent implicites, elles ne peuvent pas être discutées ni vérifiées.

Il suppose ensuite une formalisation de la résolution. Il ne s'agit plus seulement de constater qu'un système fonctionne, mais de comprendre comment il fonctionne. Dans le cas d'une application, cela peut passer par la structuration de l'architecture, la clarification des flux de données ou l'identification des dépendances. Dans le cas d'un objet physique, cela implique la compréhension des contraintes mécaniques, des choix de matériaux ou des procédés de fabrication.

Il suppose enfin une capacité de modification contrôlée. Une solution maîtrisée doit pouvoir évoluer sans rupture.

Ce processus ne peut généralement pas être assuré par un seul individu, en particulier lorsque les niveaux d'abstraction et de granularité diffèrent. Il repose sur une collaboration entre profils complémentaires, chacun apportant une maîtrise sur une partie des contraintes.

Un designer peut expliciter les logiques d'usage et les intentions d'expérience. Un ingénieur peut formaliser la structure technique et garantir la robustesse. Un profil métier peut préciser les contraintes opérationnelles réelles. Un responsable business peut assurer la cohérence économique et stratégique.

La collaboration ne consiste pas simplement à juxtaposer ces contributions. Elle consiste à traduire les contraintes d'un niveau vers un autre.

Dans ce contexte, les prototypes, les maquettes codées, les scripts ou les automatisations deviennent des supports de dialogue. Ils permettent de matérialiser des intentions et de tester des hypothèses, mais aussi de révéler les zones de non-maîtrise.

13. Le risque de stagnation dans les zones intermédiaires

Un des risques majeurs introduits par les outils actuels est la stagnation dans les zones intermédiaires de la conception.

Un prototype fonctionnel peut être perçu comme suffisant, puis utilisé tel quel sans passage par une phase de formalisation et de maîtrise. C'est typiquement le cas de certaines formes de shadow IT.

Le problème n'est pas l'existence de ces prototypes. Au contraire, ils peuvent être très utiles. Le problème apparaît lorsqu'ils deviennent des systèmes de fait, sans responsabilité claire, sans documentation, sans validation, sans intégration, et sans réelle capacité de maintenance.

Cette situation est particulièrement fréquente lorsque la pression de temps est forte ou lorsque les enjeux semblent limités. Elle conduit progressivement à une accumulation de solutions hétérogènes, difficilement maintenables, et dont les interactions deviennent incontrôlables.

L'IA amplifie ce phénomène, car elle rend la production locale beaucoup plus facile.

Il ne s'agit donc pas d'interdire ces initiatives. Ce serait probablement contre-productif. Il s'agit plutôt de mettre en place des mécanismes permettant d'identifier quand une solution doit rester un prototype, quand elle peut être tolérée comme outil local, et quand elle doit être reprise dans une logique de conception maîtrisée.

Le sujet n'est plus seulement technique. Il devient organisationnel.

14. Vers une gouvernance de la conception

C'est ici qu'apparaît un enjeu plus large : la gouvernance de la conception.

À l'ère de l'IA, les organisations ne peuvent plus considérer que la conception est réservée à quelques métiers identifiés. Des profils variés peuvent désormais produire des artefacts, automatiser des processus, générer des interfaces, prototyper des produits ou créer des outils internes. La conception devient distribuée.

Mais si la conception devient distribuée, alors la maîtrise, la responsabilité et la validation doivent être organisées.

La gouvernance de la conception ne consiste pas à interdire l'usage de l'IA. Elle ne consiste pas non plus à laisser chacun produire librement sans cadre. Elle consiste à définir comment une idée, un prototype, un outil local, une solution partagée ou un système critique changent de statut.

À chaque statut doivent correspondre des exigences différentes en matière de maîtrise, de documentation, de validation, de sécurité, d'intégration et de responsabilité.

Une organisation doit donc être capable d'identifier ce qui peut être généré librement, ce qui doit être relu, ce qui doit être repris par des profils experts, ce qui doit être documenté, ce qui doit être intégré à une architecture plus large, et ce qui doit être abandonné avant de devenir une dette.

Cette gouvernance doit aussi reconnaître la valeur des concepteurs situés. Les profils métier, business, design ou opérations ne doivent pas être considérés uniquement comme des utilisateurs à contrôler. Ils deviennent des acteurs réels de la conception, parce qu'ils formulent des contraintes essentielles.

Mais leur production doit pouvoir rejoindre une chaîne de conception maîtrisée lorsque les enjeux l'exigent.

La gouvernance de la conception consiste donc à articuler deux exigences : permettre la production rapide par ceux qui connaissent les problèmes, et organiser la montée en maîtrise lorsque les solutions deviennent importantes.

15. En conclusion : concevoir, c'est choisir où maintenir la maîtrise

La question posée par l'IA n'est pas entièrement nouvelle. Elle rend simplement plus visible un problème déjà présent dans toute pratique de conception : on ne conçoit jamais tout.

Chaque projet repose sur des choix de périmètre. On décide ce que l'on conçoit, ce que l'on assemble, ce que l'on délègue, ce que l'on achète et ce que l'on utilise tel quel. Ces choix ne sont pas périphériques : ils font partie de la conception elle-même.

Concevoir consiste donc autant à résoudre des contraintes qu'à déterminer lesquelles doivent être maîtrisées. C'est là que se situe la différence entre une production simplement fonctionnelle et une conception réellement pilotée.

L'IA intensifie cet enjeu, car elle permet de produire plus vite, avec plus d'acteurs, et parfois avec une maîtrise plus partielle de la résolution. Elle ne crée pas le problème du périmètre de conception ; elle le rend plus fréquent, plus visible et plus stratégique.

La réponse ne peut donc pas être seulement individuelle. À mesure que la conception se distribue entre métiers, designers, développeurs, experts et outils génératifs, les organisations doivent apprendre à reconnaître, encadrer et faire évoluer ces différents niveaux de maîtrise.

C'est le rôle d'une gouvernance de la conception : permettre l'exploration rapide sans confondre prototype et solution maîtrisée ; reconnaître la valeur des concepteurs situés sans ignorer les zones de non-maîtrise ; décider où la délégation est acceptable et où la compréhension doit être conservée.

À l'ère de l'IA, concevoir ne signifie donc pas tout maîtriser. Cela signifie savoir tracer, assumer et faire évoluer son périmètre de conception.