Salvatore Mosaico · 2026
Note de l’auteur
Cet essai naît d’une expérience professionnelle directe. MOSAICO est le nom donné par l’auteur à une organisation fondée sur la réutilisation et les couches. Les scènes de projet sont des simulations. Les perspectives professionnelles sont des réflexions de l’auteur, non des prévisions certaines.
Sommaire
- 1. La question : si l’IA programme, qui programmera ?
- 2. La méthode MOSAICO : réutilisation, niveaux et composition
- 3. De la réutilisation du code à celle de l’intelligence technique
- 4. Ce que l’IA sait faire et ce qu’elle ne possède pas encore
- 5. Le programmeur monte d’un niveau
- 6. Les nouvelles compétences décisives
- 7. Simulation 1 : construire une application avec l’IA
- 8. Simulation 2 : le code fonctionne, mais le produit est faux
- 9. Simulation 3 : révision, sécurité et pannes
- 10. La formation des nouveaux programmeurs
- 11. Professions en transformation et nouveaux rôles
- 12. MOSAICO à l’époque de l’IA
- 13. Conclusion : moins de saisie, plus d’ingénierie
1. La question : si l’IA programme, qui programmera ?
J’ai été un programmeur très compétent. Pendant des années, mon avantage ne consistait pas seulement à bien écrire une procédure, mais à ne pas devoir la réécrire à chaque fois. J’ai construit des bibliothèques de base pour la base de données, l’interface utilisateur et les services récurrents ; au-dessus, j’ai placé des API de niveau 1, puis les API propres à l’application, que j’appelais niveau 2. L’application finale utilisait le niveau 2. Devant un nouveau projet, une grande partie du travail — souvent environ soixante pour cent — était donc déjà disponible.
Aujourd’hui, je décris à une intelligence artificielle ce que je souhaite et je la vois produire rapidement une bonne interface, de nombreuses fonctionnalités et du code dans presque tous les langages. J’ai moi-même cessé de développer au sens traditionnel. Je n’ai pourtant pas cessé de construire des applications : j’utilise les compétences accumulées pour orienter l’outil, repérer les manques et transformer un résultat rapide en bon produit.
De cette expérience naît une question : quel sera l’avenir des programmeurs ? Si la production matérielle du code devient de moins en moins coûteuse, la profession perd-elle sa valeur ou change-t-elle d’objet ?
La thèse de ces pages est que le programmeur ne disparaît pas : il monte d’un niveau. La valeur passe de la saisie d’instructions à la compréhension du problème, de l’implémentation locale à l’architecture, de la syntaxe au contrôle du comportement global. La machine peut multiplier le code ; quelqu’un doit encore décider quel système mérite d’exister, comment le composer et quand il est assez fiable pour être livré.
L’avenir n’appartient pas à qui écrit le plus de lignes, mais à qui transforme le mieux une intention en système vérifiable.
2. La méthode MOSAICO : réutilisation, niveaux et composition
Le nom MOSAICO exprime l’idée : on ne sculpte pas chaque application dans un bloc unique, on la compose de pièces déjà conçues, testées et compatibles. La réutilisation n’abolit pas la créativité ; elle la déplace de la fabrication de chaque élément vers leur choix et leur disposition.
L’ARCHITECTURE MOSAICO
Bibliothèques de base : composants stables pour bases de données, interface utilisateur, accès aux données, communication et services communs.
Niveau 1 : API fonctionnelles générales masquant les détails des bibliothèques et offrant des opérations cohérentes aux projets.
Niveau 2 : API propres à l’application, décrivant le domaine et utilisant exclusivement le niveau 1.
Application : interface et parcours finaux construits à travers les capacités exposées par le niveau 2.
La règle selon laquelle le niveau 2 utilise uniquement le niveau 1 est décisive. Elle empêche l’application de dépendre directement de dizaines de détails techniques. Un changement de base de données ou de bibliothèque graphique devrait être absorbé par les couches inférieures. Une modification d’une règle métier relève principalement du niveau 2.
Ce n’est pas seulement une technique d’économie de temps : c’est un gouvernement de la complexité. Chaque niveau possède un vocabulaire, une mission et une frontière. Les couches inférieures sont générales ; les supérieures se rapprochent progressivement du problème réel.
Les soixante pour cent déjà prêts ne signifient pas que tous les projets sont identiques. Beaucoup de difficultés ne sont simplement pas nouvelles : authentification, persistance, validation, affichage, notifications, gestion des erreurs. Les séparer du noyau spécifique évite de confondre infrastructure et valeur du produit.
3. De la réutilisation du code à celle de l’intelligence technique
L’IA élargit radicalement le principe de réutilisation. Une bibliothèque traditionnelle réutilise du code écrit. Un modèle génératif réutilise des schémas appris à partir d’immenses quantités d’exemples et les adapte à une demande nouvelle. Il ne récupère pas seulement une fonction identique : il synthétise une implémentation possible.
MOSAICO et l’IA ne sont cependant pas la même chose. MOSAICO crée des dépendances explicites, des frontières décidées et des composants dont le concepteur maîtrise l’identité. L’IA génère rapidement une solution, mais tend à optimiser la demande immédiate. Sans contraintes architecturales, elle peut dupliquer la logique, traverser les couches, choisir des bibliothèques incohérentes et produire un système élégant en surface mais coûteux à maintenir.
La nouvelle réutilisation a donc besoin de l’ancienne rigueur. L’IA accélère la production ; l’architecture empêche que cette accélération devienne accumulation. Plus on peut générer de code, plus importent les règles limitant son emplacement et ses dépendances.
L’expérience du programmeur conserve ici un avantage énorme. Celui qui a vu des systèmes grandir, tomber en panne et devenir ingérables reconnaît les coûts futurs cachés dans un raccourci présent. La machine voit bien le fragment demandé ; l’architecte doit voir le cycle de vie.
4. Ce que l’IA sait faire et ce qu’elle ne possède pas encore
L’IA actuelle génère efficacement structures de projet, composants graphiques, requêtes, tests, documentation, conversions entre langages et fonctionnalités courantes. Elle est aussi un excellent interlocuteur pour explorer des alternatives ou expliquer du code inconnu.
Mais un programme qui compile et un écran agréable ne prouvent pas que le produit soit juste. L’IA ne possède pas spontanément l’histoire de l’organisation, les compromis convenus avec le client, les exceptions non documentées, le sens économique d’une erreur ni la responsabilité des conséquences. Elle peut recevoir ce contexte, mais quelqu’un doit le sélectionner, le maintenir cohérent et remarquer ce qui n’a pas été dit.
QUATRE DISTINCTIONS ESSENTIELLES
Code valide / exigence correcte : le logiciel peut parfaitement exécuter la mauvaise chose.
Démo / produit : une démonstration heureuse ne prouve ni sécurité, ni résilience, ni accessibilité, ni maintenabilité.
Test réussi / risque maîtrisé : les tests couvrent les scénarios choisis ; ils ne certifient pas automatiquement ceux qu’on a oubliés.
Réponse plausible / décision responsable : une solution convaincante exige encore un responsable, des contrôles et des critères d’acceptation.
Dire que l’IA « ne sait pas faire MOSAICO » a donc un sens précis : elle peut en réaliser les pièces et respecter les règles si nous les lui fournissons ; elle ne garantit pas de manière autonome la continuité architecturale. Sans mémoire organisée, vérifications automatiques et supervision, chaque demande risque de lui faire réinventer le système.
5. Le programmeur monte d’un niveau
Longtemps, programmer a signifié traduire un algorithme en instructions rigoureuses. Cette traduction peut maintenant être partiellement déléguée. Le programmeur conçoit de plus en plus le langage intermédiaire de la collaboration entre personne et machine : spécifications, contrats d’API, exemples, tests, schémas de données, contraintes et critères de qualité.
Savoir bien demander en langage naturel ne suffit pas. Le prompting n’est que l’entrée. La véritable compétence consiste à maintenir une cohérence à travers des dizaines de demandes, comprendre le code produit, prévoir les interactions et construire un processus rendant les erreurs visibles tôt.
Le passage va de l’auteur de chaque ligne au responsable du système ; du solveur de tâches isolées au concepteur de frontières ; du chercheur de syntaxe au juge des alternatives ; de l’exécutant au directeur technique d’agents logiciels.
Cela ne supprime pas le besoin de savoir programmer. Sans comprendre variables, structures de données, concurrence, transactions, protocoles et complexité, on ne contrôle pas ce que génère l’IA. Le code sera peut-être moins souvent écrit à la main, mais devra être lu plus attentivement.
6. Les nouvelles compétences décisives
Compréhension du domaine. Transformer les besoins vagues en règles explicites ; distinguer la demande du client des besoins réels du processus.
Architecture et modularité. Définir responsabilités, dépendances, contrats et direction des appels. C’est le cœur de MOSAICO, plus important encore lorsque le code naît rapidement.
Spécification. Écrire critères d’acceptation, cas limites, exemples et invariants. Une demande précise vaut mieux que de nombreuses corrections tardives.
Lecture et révision du code. Comprendre comportements, effets secondaires et hypothèses d’un code qu’on n’a pas écrit. Le programmeur de demain lira peut-être davantage qu’il ne saisira.
Tests stratégiques. Choisir ce qu’il faut prouver, et pas seulement générer des tests : propriétés, frontières, erreurs, intégrations, régressions et scénarios hostiles.
Sécurité et confidentialité. Gérer identités, autorisations, secrets, données personnelles, dépendances et surfaces d’attaque. L’IA accélère aussi la production de vulnérabilités plausibles.
Observabilité et diagnostic. Journaux, métriques, traces et alertes doivent expliquer le comportement en production. Une application rapidement générée reste opaque si elle ne peut raconter ce qui lui arrive.
Évaluation des outils. Choisir modèles, bibliothèques et plateformes sans attacher le produit à une mode. Connaître coûts, licences, qualité, portabilité et dépendance au fournisseur.
Communication et responsabilité. Expliquer les décisions aux clients et collègues ; déclarer l’usage de l’IA ; savoir qui approuve une modification et répond du résultat.
7. Simulation 1 : construire une application avec l’IA
Imaginons un système de réservation pour un petit centre médical. Une demande précipitée serait : « crée une application moderne pour gérer les rendez-vous ». L’IA produirait probablement un bel écran, une base et quelques opérations. Mais le projet n’est pas encore défini.
RÉUNION — DE L’IDÉE AU CONTRAT
Client : Je veux qu’un patient réserve rapidement.
Concepteur : Peut-il réserver toute prestation ? Faut-il une prescription ? Qui voit le motif de la visite ?
Client : Certaines prestations exigent une approbation ; le secrétariat voit les données administratives, pas les notes cliniques.
Concepteur : Définissons alors les rôles, états de réservation, autorisations et conservation des données avant de générer les écrans.
IA : Reçoit contrats d’API, schéma de données, exemples et critères d’acceptation ; réalise une première version.
Dans MOSAICO, le niveau 1 offre des capacités générales : authentifier, enregistrer une entité, envoyer une notification, consigner un événement. Le niveau 2 expose les opérations métier : demander, approuver ou annuler une réservation, vérifier la disponibilité. L’interface appelle uniquement ces opérations.
La valeur du programmeur n’est pas d’avoir saisi le module calendrier. Elle est d’avoir découvert les règles cachées, empêché l’interface de contourner les autorisations et transformé l’exigence en contrats contrôlables.
L’IA raccourcit le temps entre spécification et prototype, permettant de montrer tôt le produit et de corriger la compréhension. Mais la rapidité ne doit pas faire confondre prototype et achèvement.
8. Simulation 2 : le code fonctionne, mais le produit est faux
Une plateforme commerciale applique automatiquement dix pour cent de réduction aux commandes dépassant cent euros. L’IA réalise la règle et tous les tests proposés passent. Après livraison, on découvre que le seuil doit être hors TVA, que certains produits sont exclus et que deux promotions ne sont pas cumulables.
RÉVISION — LA PREMIÈRE ERREUR N’EST PAS DANS LE CODE
Développeur junior : La fonction est correcte : si total > 100, elle applique dix pour cent.
Responsable produit : Correcte par rapport à une spécification incomplète.
Architecte : La logique promotionnelle est dans l’interface. Elle doit être au niveau 2, indépendante de l’UI, et recevoir un total précisément défini.
Réviseur : Ajoutons des exemples contrastés : 99 euros hors TVA ; 110 euros de produits exclus ; deux promotions simultanées.
Le débogage ne concerne pas seulement le code : exigences, architecture et modèle mental se déboguent aussi. L’IA peut corriger rapidement une fonction, mais ne devine pas fiablement une politique commerciale jamais formulée.
Le programmeur doit poser des questions produisant des différences observables. Un bon cas de test ne confirme pas seulement le comportement attendu ; il sépare des interprétations alternatives de l’exigence.
9. Simulation 3 : révision, sécurité et pannes
Une fonction générée pour supprimer un utilisateur efface la ligne principale et répond « opération réussie ». Elle paraît complète. Mais qu’advient-il des commandes, documents fiscaux, consentements et journaux ? La suppression est-elle permise ou faut-il anonymiser ? Un administrateur peut-il se supprimer lui-même ? L’opération est-elle réversible ?
CONTRÔLE AVANT LIVRAISON
Correction : invariants, transactions et comportement en cas d’exécution partielle sont-ils définis ?
Sécurité : identité et autorisation sont-elles vérifiées côté serveur, pas seulement dans l’UI ?
Données : conservation, minimisation, audit et relations entre entités sont-ils respectés ?
Résilience : que se passe-t-il si la base, le réseau ou un service externe ne répond pas ?
Observabilité : un opérateur comprendra-t-il ce qui s’est produit sans exposer de données sensibles ?
Le logiciel professionnel ne coïncide donc pas avec son texte source. Il comprend données, infrastructures, procédures, personnes, responsabilités et conséquences. L’IA peut aider chaque contrôle ; elle ne dispense pas de décider lesquels sont obligatoires.
La productivité ne se mesure pas uniquement en fonctionnalités générées. Une équipe est productive lorsqu’elle livre de la valeur sans accumuler des risques invisibles. Le code d’aujourd’hui devient la maintenance de demain.
10. La formation des nouveaux programmeurs
Si les étudiants génèrent un programme entier, les évaluer uniquement sur l’écriture à partir de zéro conduit à l’usage caché de l’IA ou à des exercices artificiellement surveillés. Il faut intégrer l’outil et recentrer la formation sur la pensée informatique.
Les bases restent indispensables : algorithmes, structures de données, logique, systèmes d’exploitation, réseaux, bases de données et principes des langages. Non pour mémoriser chaque détail, mais pour formuler des hypothèses et diagnostiquer des erreurs.
UNE ÉPREUVE POSSIBLE
Partie A — Lecture : expliquer le comportement d’un code généré, ses dépendances et effets secondaires.
Partie B — Conception : définir API, données, invariants et cas limites avant l’implémentation.
Partie C — IA : générer une solution en déclarant demandes, outils et modifications.
Partie D — Vérification : écrire des tests capables de réfuter la solution et analyser une erreur introduite volontairement.
Partie E — Défense orale : justifier les choix et adapter le projet à une exigence modifiée.
Un exercice utile fournit une application fonctionnelle mais mal conçue : les étudiants doivent la séparer en couches, réduire les dépendances et expliquer ce qui devient réutilisable. C’est très proche de MOSAICO et du travail réel.
Apprendre à programmer avec l’IA, c’est aussi apprendre à ne pas déléguer trop tôt. D’abord un plan, ensuite l’aide ; d’abord une prévision du comportement, ensuite l’exécution ; d’abord un critère de correction, ensuite l’acceptation.
11. Professions en transformation et nouveaux rôles
Les prévisions sérieuses sur l’emploi appellent à la prudence : l’exposition à l’IA concerne surtout des tâches, pas automatiquement des professions entières. Pour les juniors, le risque concret est la réduction des activités simples par lesquelles on apprenait sur le terrain. Il faut donc des apprentissages permettant encore diagnostic, révision et responsabilité croissante.
Dans la perspective proposée ici, certaines activités perdront de leur valeur relative : code répétitif, recherche syntaxique élémentaire, conversion mécanique de formats, CRUD standard, premières interfaces. La valeur grandira pour l’intégration de systèmes, la gouvernance des données, la sécurité, l’expérience utilisateur, l’évaluation des résultats de l’IA et la responsabilité du résultat.
Des rôles hybrides pourraient émerger : product engineers entre problème et implémentation ; architectes de plateformes construisant les « niveaux 1 » de l’entreprise ; responsables qualité des systèmes générés ; spécialistes sécurité des chaînes assistées ; conservateurs du contexte maintenant spécifications, documentation et règles accessibles aux agents.
Le titre compte moins que les compétences combinées : profondeur technique, connaissance métier, communication et discipline de contrôle. Les références européennes citées décrivent une pénurie de spécialistes ICT avancés, notamment en IA et sécurité : la demande ne disparaît pas simplement, elle devient plus sélective.
Le danger majeur n’est pas que l’IA remplace tous les programmeurs. C’est qu’une organisation confonde facilité de produire une démo et capacité à gouverner un système réel.
12. MOSAICO à l’époque de l’IA
MOSAICO peut passer d’une collection de bibliothèques à une plateforme intelligible aussi pour l’IA. Ses niveaux deviennent des contrats autant que du code : documentation concise, exemples, schémas, tests automatiques et interdictions explicites.
Le niveau 1 fournit des chemins préférentiels sûrs pour données, authentification, journalisation, erreurs et configuration. Le niveau 2 parle la langue de l’application et empêche l’UI de connaître l’infrastructure. L’IA reçoit ces règles et génère dans ces frontières.
MOSAICO + IA — PROCESSUS
1. Intention : décrire objectif, utilisateurs, contraintes et événements à empêcher.
2. Architecture : attribuer les responsabilités au bon niveau et définir les contrats.
3. Génération : demander une modification petite, traçable et cohérente avec les composants existants.
4. Vérification : tests, analyses, révision humaine et cas limites.
5. Consolidation : promouvoir une capacité réellement générale au niveau réutilisable approprié.
L’IA ne dépasse pas la méthode : celle-ci devient la structure lui permettant de produire sans désorganiser le système. L’intelligence générative fournit la vitesse locale ; MOSAICO, la mémoire architecturale.
Autre possibilité : généraliser un composant coûtait parfois plus que son bénéfice immédiat. L’IA réduit le coût de documentation, de test et d’adaptation. La réutilisation peut croître, sans devenir abstraction prématurée : promouvoir une pièce seulement après avoir reconnu sa véritable généralité.
13. Conclusion : moins de saisie, plus d’ingénierie
Programmer n’a jamais été seulement écrire du code. Celui-ci était le moyen obligé de transformer une intention en comportement. Une machine peut désormais produire une partie de ce moyen. La responsabilité du comportement demeure.
Le programmeur devra définir les problèmes, dessiner les frontières, composer les services, lire le code, concevoir les épreuves, contrôler les risques et comprendre les utilisateurs. Connaître assez l’IA pour l’exploiter, et assez l’informatique pour ne pas être trompé.
Mon expérience aboutit à un paradoxe apparent : j’ai cessé de développer au sens ancien, mais je construis toujours des applications. L’IA accomplit davantage de travail matériel ; les compétences acquises me permettent de choisir, diriger, corriger et reconnaître un bon produit.
MOSAICO anticipait cette transformation. L’avantage était déjà d’organiser l’acquis et de composer rapidement une solution nouvelle, non de tout réécrire. Aujourd’hui, les pièces peuvent être générées ; le dessin de la mosaïque reste essentiel.
L’IA ne rend pas le programmeur inutile. Elle dévalorise la simple production de lignes et valorise la capacité d’attribuer à chacune une place, un but, une épreuve et une responsabilité.
L’avenir du programmeur n’est pas de rivaliser avec la vitesse d’écriture de la machine. C’est de savoir lui dire quoi construire, comprendre ce qu’elle a réellement construit et répondre des conséquences.
Références essentielles
- International Labour Organization, Generative AI and Jobs: A Refined Global Index of Occupational Exposure (2025) — Transformation des tâches, non disparition automatique des professions.
- International Labour Organization, The future of work: How will junior programmers be affected? (2025) — Parcours d’entrée et activités formatrices des juniors.
- European Commission, State of the Digital Decade 2025 — IA, cloud et big data, avec pénurie de compétences ICT avancées.
- ACM / IEEE-CS / AAAI, Computer Science Curricula 2023 (2024) — Compétences, responsabilité et IA dans la formation informatique.
- David Parnas, On the Criteria To Be Used in Decomposing Systems into Modules (1972) — La modularité masque les décisions susceptibles de changer.
- Fred Brooks, No Silver Bullet (1986; Computer, 1987) — Complexité accidentelle et essentielle du logiciel.
Texte destiné à la publication en ligne. De courts extraits peuvent être cités en indiquant l’auteur et le titre.
À lire aussi
Les mathématiques à l’époque de l’intelligence artificielle