Salvatore Mosaico · 2026
La collaboration entre intelligence artificielle et concepteur : du résultat correct à la qualité du système.
Une application fonctionne : les pages s’ouvrent, les données sont enregistrées, les calculs donnent les résultats attendus. Peut-on dire que le travail est terminé ?
Pas nécessairement. Le bon fonctionnement est indispensable, mais ne suffit pas à décrire la qualité d’un logiciel. Il faut aussi se demander s’il est compréhensible, modifiable et réutilisable. Et surtout : où les responsabilités ont-elles été placées ?
Le développement avec l’intelligence artificielle rend cette question particulièrement importante. L’IA peut réaliser rapidement les fonctionnalités demandées, mais une succession de solutions correctes ne garantit pas, à elle seule, une architecture cohérente.
Sommaire
- 1. Une fonctionnalité à la fois, une architecture prend aussi forme
- 2. La comparaison qui a révélé le problème
- 3. Simplifier l’utilisation, sans nier la complexité
- 4. Compter les objets ne suffit pas à comprendre un système
- 5. Quand les spécifications viennent du système
- 6. Avec l’IA, documenter après signifie aussi vérifier
- 7. Une page web qui documente la base de données
- 8. La collaboration qui produit de la qualité
- Conclusion
1. Une fonctionnalité à la fois, une architecture prend aussi forme
Le travail avec l’IA avance souvent par demandes successives :
« Ajoute un jeu. »
« Maintenant, rends-le multilingue. »
« Introduis des salles pour jouer à distance. »
« Ajoute les outils d’administration. »
« Prépare les statistiques. »
Chaque demande semble concerner une fonction. En réalité, elle peut entraîner des décisions sur la structure des données, les dépendances et la répartition de la logique.
L’IA ne fait donc pas qu’écrire du code : elle participe à la conception, même lorsque personne ne lui a explicitement demandé de concevoir l’ensemble du système.
Le risque est de traiter chaque nouveau besoin comme un problème local, en ajoutant une solution sans réexaminer suffisamment les précédentes.
Cela ne signifie pas que l’IA produit inévitablement de mauvais logiciels. Cela signifie que la qualité dépend aussi des orientations reçues, du contexte disponible et de la révision des décisions accumulées.
2. La comparaison qui a révélé le problème
La discussion est née de la comparaison de deux bases de données.
Dans le site développé avec l’IA, 36 tables avaient été recensées, sans vues, procédures ni déclencheurs. Le précédent projet SPIAGGE comportait 10 tables, 59 vues et 2 déclencheurs ; ceux-ci appelaient trois procédures, récupérées séparément parce qu’elles ne figuraient pas dans le dump examiné.
Ces nombres ne permettent pas d’attribuer une note. Les projets répondent à des besoins différents, et une vue ne remplace pas nécessairement une table.
La comparaison a toutefois révélé une différence architecturale : dans le premier système, une grande partie de la logique résidait dans le code applicatif ; dans le second, une part importante était organisée dans la base de données.
L’observation décisive du concepteur a été la suivante :
Dans mon PHP, je n’écris pas de jointures. J’interroge les vues avec SELECT, WHERE et ORDER BY.
Il ne s’agissait pas de renoncer aux relations entre les données, mais de les avoir déjà définies dans la couche sous-jacente.
3. Simplifier l’utilisation, sans nier la complexité
Une page peut avoir besoin d’un devis complet comprenant ressources, périodes, prix et remises.
Si ces éléments sont reconstruits en PHP, la personne qui développe la page doit connaître les tables, les liens et les formules. Si une vue les présente déjà sous la forme requise, le code applicatif peut simplement demander le résultat.
La complexité ne disparaît pas : elle est traitée au niveau approprié et rendue réutilisable.
La personne qui maintient ce niveau doit bien connaître la base de données. Celle qui réalise une page n’a pas nécessairement besoin de connaître toutes les étapes internes du calcul.
Cela permet aussi une répartition du travail : le concepteur définit les services et les règles ; le développeur applicatif les utilise au moyen d’une interface plus simple.
Cela ne signifie pas que toute opération doit résider dans la base de données. Son emplacement doit être un choix conscient, et non une conséquence fortuite de la dernière demande.
4. Compter les objets ne suffit pas à comprendre un système
Le concepteur raconte une expérience antérieure : un système en service depuis des années, avec environ 120 tables et 1 200 vues. Deux sociétés de développement, sollicitées successivement pour le remplacer, ont tenté de refaire le système en partant de la base de données, sans parvenir à achever le remplacement.
Ce témoignage ne démontre pas, à lui seul, pourquoi ces tentatives ont échoué. Il suggère néanmoins une question essentielle :
Avant de remplacer la structure, avaient-elles compris les services qu’elle offrait et les règles qu’elle incorporait ?
Un grand nombre de vues peut représenter un empilement inutile, mais aussi une décomposition du problème mûrie au fil des années. Pour distinguer les deux, il faut étudier les définitions, les dépendances et les usages.
En même temps, une architecture de qualité doit pouvoir être transmise à d’autres personnes. Si ses raisons restent uniquement dans la tête de son auteur, une partie importante du projet demeure fragile.
C’est ici qu’intervient la documentation.
5. Quand les spécifications viennent du système
Il y a une trentaine d’années, le concepteur avait déjà vu fonctionner un processus de documentation automatique : en se connectant à Oracle avec les identifiants appropriés, un outil lisait la structure de la base et, à l’aide de macros et d’un modèle Word, produisait un document d’environ 250 pages, organisé en chapitres et sections. Dans son souvenir, cette génération s’effectuait sans erreur.
Le changement ne concernait pas seulement la rapidité.
Dans le processus traditionnel qu’il décrit, le concepteur remettait un document contenant les structures de données, puis le programmeur de la base les implémentait. Le document et l’implémentation étaient deux représentations à maintenir en cohérence.
Dans le nouveau processus, le concepteur implémentait directement la structure, dont on tirait ensuite la documentation.
Les spécifications, selon son expression, « revenaient de l’implémentation » : elles décrivaient le système réalisé, au lieu de n’être que des instructions pour le construire.
Cela ne supprime pas la nécessité de définir au préalable les objectifs, exigences et contraintes. Cela évite toutefois de recopier manuellement des informations structurelles déjà connues de la base.
6. Avec l’IA, documenter après signifie aussi vérifier
Dans notre démarche, le projet s’est développé par fonctionnalités successives. La documentation de la structure effectivement réalisée doit donc suivre l’implémentation.
A posteriori ne signifie pas nécessairement à la fin. Cela peut vouloir dire après chaque modification importante.
La documentation devient ainsi un outil pour observer ce que l’IA a contribué à construire :
- Quelles structures ont été ajoutées ?
- Quelles responsabilités ont été dupliquées ?
- Où résident les règles ?
- Quels composants dépendent des mêmes données ?
- Existe-t-il des services disponibles que le nouveau code n’utilise pas ?
C’est ce qui s’est passé dans cette discussion : la documentation de la base a rendu visible une différence de conception que le simple fonctionnement des pages n’aurait pas mise en évidence.
7. Une page web qui documente la base de données
L’évolution naturelle est une page d’administration qui lit les métadonnées de la base et produit un document selon un modèle prédéfini.
Un chapitre pour les tables, une section pour chacune, un tableau des champs et des types. Puis les relations, vues, déclencheurs et procédures, avec sommaire et export Word ou PDF.
La source peut être un dump ou une connexion côté serveur, protégée et dotée des seules autorisations nécessaires.
Il faut distinguer deux activités :
Extraire la structure est une tâche déterministe. Les noms, types et contraintes ne doivent pas être inventés par l’IA.
En expliquer le sens peut bénéficier de l’IA. Une requête complexe peut être décrite, une procédure résumée, une dépendance mise en évidence. Les interprétations doivent toutefois rester distinctes des faits extraits.
De plus, si la logique réside dans le PHP, documenter la base ne suffit pas à documenter l’application : il faut également analyser le code.
8. La collaboration qui produit de la qualité
Le lien avec la méthode MOSAICO est direct.
Dans le passage de RandomNumero à RandomRange, le problème n’était pas seulement d’obtenir un nombre dans le bon intervalle. Il fallait reconnaître une capacité déjà disponible et l’utiliser sans reproduire son mécanisme.
Le même principe s’applique à une vue, une procédure ou un service applicatif.
L’utilisateur expérimenté ne se contente pas d’indiquer à l’IA ce qui manque. Il lui précise aussi les responsabilités existantes, les interfaces à respecter et les duplications à éviter.
L’IA peut, à son tour, aider à expliciter les alternatives, reconstituer les dépendances et vérifier la cohérence des nouvelles modifications.
La collaboration devient donc un cycle : clarifier le besoin, identifier la responsabilité, implémenter, vérifier le résultat et mettre à jour la documentation. Puis réexaminer l’ensemble.
Conclusion
L’IA peut accélérer considérablement la production de code. Mais produire davantage de code, plus vite, ne signifie pas automatiquement construire un meilleur système.
La valeur de l’expérience réside aussi dans la capacité à reconnaître ce qui ne doit pas être réécrit, à garder des interfaces simples et à rendre les décisions compréhensibles.
Si l’IA construit le projet une fonctionnalité à la fois, la documentation générée à partir du système permet au concepteur de retrouver une vision et une maîtrise de l’ensemble.
C’est cette collaboration plus étroite qui permet de passer d’un produit simplement fonctionnel à un produit de qualité : non pas en demandant seulement à l’IA d’ajouter quelque chose, mais en réfléchissant ensemble à sa place et à son intégration avec l’existant.