D'une idée à la mise en production d'une application : ce que six mois de projet IA m'ont vraiment appris

Aujourd’hui l’IA est vue comme un accélérateur universel, capable de rendre accessibles des compétences qui étaient réservées à des experts. Mais qu’en est-il vraiment lorsqu’on l’utilise dans un projet concret, en entreprise, porté par une stagiaire sans prétention d’expertise dans les domaines requis ?

C’est la question à laquelle ces six mois de stage chez Nobori Partners m’ont permis de répondre :

• L’objectif : automatiser un cas d’usage métier en développant une application web de A à Z, de la phase de cadrage jusqu’à la mise en production
• Le résultat : une application web entièrement fonctionnelle et déployée en production (frontend + backend)
• Le constat : l’IA est un outil remarquable pour couvrir seule un périmètre qui mobilise normalement plusieurs expertises métier, à condition de l’utiliser avec méthode, curiosité et esprit critique

En tant que stagiaire issue d’une école d’ingénieur avec une formation en data science, j’avais développé un esprit analytique et une méthodologie pour aborder des problèmes complexes. Mais je n’étais pas experte dans tous les domaines qu’un tel projet recouvre. Développer une application web de bout en bout mobilise simultanément des compétences issues de plusieurs métiers distincts :

• Product Owner : réalisation de spécifications en accord avec les besoins du métier, puis prototypage
• Architecte SI : rédaction d’un dossier d’architecture pour détailler les liens entre les composants applicatifs (schémas fonctionnel, applicatif et technique)
• Développement web : implémentation du code pour développer les fonctionnalités et réaliser les connexions avec les outils tiers
• Cybersécurité : sécuriser une application web utilisant de l’IA (règles OWASP, injection de prompt, authentification)
• Data et DevOps : mise en production de l’application (hébergement, gestion de la base de données, monitoring, exposition Internet)

Ce sont ces domaines qui m’ont été rendus accessibles grâce à trois leviers combinés : les outils IA, la documentation technique, et l’expertise et les échanges avec les consultants qui m’ont entourée tout au long de ce stage.

Je vous détaille dans la suite de cet article mon retour d’expérience sur ce que l’IA permet réellement, là où elle excelle, là où elle montre ses limites, et les convictions que j’en ai tirées sur ce projet.

Le prototypage : là où l’IA excelle, à condition de bien cadrer le besoin

L’IA rend le prototypage accessible à tous

La phase de spécification et de prototypage est aujourd’hui probablement la plus accessible grâce aux outils IA. Des solutions comme Lovable permettent de transformer des descriptions écrites en langage naturel en code fonctionnel, rendant cette étape accessible même à des profils non techniques. L’IA génère le code à partir de nos descriptions et, en quelques heures, on obtient une maquette dynamique

Une fois le prototype validé, la phase d’implémentation bénéficie du même effet d’accélération. En s’appuyant sur une flotte d’agents pour guider le développement, on arrive à maintenir la cohérence entre les milliers de lignes de code. Ces agents ont permis de tracer les décisions techniques, d’assurer la cohérence entre les fichiers et d’éviter les régressions. Pour quelqu’un qui n’est pas développeur de métier, cet accompagnement structuré est une véritable sécurité

Le cadrage du besoin : une compétence indispensable

La facilité de l’outil ne dispense pas d’une réflexion approfondie en amont. Et c’est là que réside la vraie valeur ajoutée de l’humain dans cette phase

Une chose que l’IA ne fait pas seule : comprendre précisément ce qu’on veut. Sur ce projet, la phase de spécification est un point central : comprendre le besoin métier, distinguer ce qui est indispensable de ce qui est agréable à avoir, et traduire tout cela en spécifications suffisamment précises pour qu’elles puissent être exécutées par l’IA

C’est là qu’on observe l’un des avantages du prototypage rapide rendu possible par l’IA. Avant, recueillir des retours utilisateurs supposait des allers-retours longs entre des maquettes figées et le cycle de design, rendant difficile la projection sur le produit final. Aujourd’hui, une maquette dynamique et interactive peut être générée rapidement, ce qui permet d’observer comment les utilisateurs interagissent avec l’interface et d’ajuster les spécifications avant la phase de développement

Ainsi, ce travail de cadrage, qui peut être perçu comme préliminaire, est en réalité ce qui détermine la qualité de tout ce qui suit. Une spec vague produit un prototype vague. Une spec claire, détaillée et précise produit un résultat rapide, cohérent et utilisable. Le principe garbage in, garbage out s’applique ici : l’IA exécute ce qu’on lui donne, elle ne peut pas deviner ce qu’on ne lui dit pas

Le vrai défi n’est pas de construire un prototype, c’est de le mettre en production

Selon la RAND Corporation (2024), plus de 80% des projets IA échouent avant d’atteindre la production. Après avoir vécu ce projet de l’intérieur, je comprends mieux pourquoi

Prototyper, c’est transformer un besoin en code : facilement réalisable avec de l’IA. Déployer, c’est opérer une infrastructure : cela demande une réelle expertise technique. Ce sont deux métiers différents

Passer d’un prototype à une application déployée implique des dizaines de décisions concrètes. Faut-il héberger la base de données soi-même ou opter pour une solution managée ? Gérer les secrets dans le code ou via un Secret Manager ? Conserver un système d’authentification email/mot de passe ou le supprimer au profit d’un SSO Microsoft uniquement, pour des raisons de sécurité ? Ce sont ces arbitrages, pris en connaissance de cause, qui font la différence entre une application fragile et une application en production

L’IA peut expliquer ce qu’est un reverse proxy, comment fonctionne une politique réseau ou à quoi sert un certificat TLS. Mais elle ne peut pas choisir à notre place la bonne solution selon nos contraintes. Ces décisions requièrent du jugement, de l’expérience et une compréhension fine du contexte opérationnel. Sans ces bases, on risque de prendre pour acquises les recommandations de l’IA, sans être en mesure d’en évaluer la pertinence ou les risques associés. C’est précisément pourquoi la mise en production représente le véritable point de blocage pour la majorité des projets

Ce que mettre une application en production implique vraiment

La sécurité d’une application IA : deux niveaux, pas un

C’est l’un des sujets les plus critiques du développement d’applications web, surtout lorsqu’on travaille avec des LLM

Sécuriser une application web classique implique des pratiques bien documentées : authentification robuste, gestion des rôles, conformité OWASP, rotation des secrets. Une application qui utilise des LLM introduit une surface d’attaque supplémentaire, spécifique et souvent ignorée : l’injection de prompt. Le principe est simple : une donnée externe (une information transmise à un chatbot, un document PDF, le contenu d’un site web) peut contenir des instructions déguisées en texte, qui vont manipuler le comportement du modèle IA

La principale leçon à retenir est la suivante : il ne faut jamais laisser l’IA avoir accès à des ressources critiques tout en manipulant des données non maîtrisées. Ce cloisonnement de l’architecture doit être une décision de sécurité prise dès la conception, pas une correction tardive. Sur ce projet, cela s’est traduit concrètement dès le départ : en production, l’application ne communique jamais directement avec le modèle IA. Ce sont les pipelines d’orchestration qui enrichissent les données et écrivent en base ; l’application se contente de lire

La couche data et infrastructure : un empilement de briques qu’aucune IA ne monte à notre place

Une fois l’application sécurisée, il reste à la faire vivre quelque part. Et c’est ici que j’ai le plus mesuré la différence entre faire tourner du code sur ma machine et exploiter une application en production. Chaque brique de cette couche est une compétence à part entière, et surtout, aucune ne s’improvise à partir d’une simple question posée à l’IA.

Il a d’abord fallu comprendre comment empaqueter l’application (conteneur Docker), puis la faire tourner de manière fiable sur un cluster Kubernetes (avec ses notions de pods, de nœuds, de réplicas). Puis exposer cette application à Internet sans l’exposer aux attaques : c’est le rôle de Cloudflare (DNS, HTTPS, filtrage), tandis que la base de données, elle, reste isolée dans un réseau privé, injoignable depuis l’extérieur. Rien que cette question, « qui a le droit de parler à qui, et par quel chemin ? », mobilise des notions de réseau qu’il faut savoir maîtriser

Vient ensuite tout ce qui rend un déploiement robuste :

• une chaîne de CI/CD pour tester, vérifier et livrer le code automatiquement à chaque changement
• une gestion des secrets rigoureuse (un coffre-fort, un mécanisme d’injection dans le cluster, des identités machine, et une procédure de rotation des clés) pour ne jamais écrire un mot de passe en clair
• une stratégie de sauvegarde et de restauration de la base, testée pour de vrai
• du monitoring : savoir, en temps réel, si l’application est tombée, si un traitement a échoué ou si une erreur remonte, plutôt que de l’apprendre par un utilisateur mécontent

Le point commun de toutes ces briques : elles demandent du temps pour être comprises, pas seulement appliquées. L’IA m’a expliqué ce qu’était chacune d’elles, m’a fait gagner des heures de lecture et m’a évité bien des impasses. Mais elle ne pouvait pas décider à ma place s’il fallait héberger la base moi-même ou prendre une version managée, ni arbitrer entre coût, sécurité et conformité, ni deviner les contraintes internes de l’entreprise. Ces décisions supposent d’avoir assimilé les notions sous-jacentes. C’est précisément cet effort de montée en compétence qui sépare un prototype d’une application réellement en production

Les conditions d’un usage efficace de l’IA : ce qu’il faut développer

Fort de cette expérience, deux compétences se révèlent déterminantes pour tirer pleinement parti de l’IA dans un projet de développement. Et elles n’ont, au fond, rien de technique

La curiosité comme moteur d’apprentissage

Tout au long du projet, des choix techniques ont dû être effectués : quelle solution d’hébergement ? Comment gérer la base de données ? Comment sécuriser les accès réseau ? Ces choix ne peuvent pas reposer uniquement sur ce que l’IA propose. Ils requièrent une montée en compétence active sur les sujets qu’on maîtrise le moins

C’est en sollicitant des experts, en lisant la documentation et en testant plusieurs approches qu’on gagne la capacité de décider, pas en faisant confiance par défaut

La combinaison qui a rendu ce projet possible n’était pas l’IA seule. C’était l’IA, la documentation, et l’expertise des consultants qui m’ont entourée, chacun jouant un rôle complémentaire

L’esprit critique comme garde-fou

La deuxième compétence est peut-être la plus importante : savoir challenger les réponses de l’IA. L’IA peut halluciner, proposer des solutions sous-optimales pour un contexte qu’elle ne connaît pas, ou ignorer des contraintes qu’on ne lui a pas explicitées

Développer cet esprit critique, c’est croiser les sources, comprendre le pourquoi derrière une recommandation, savoir reconnaître quand une réponse mérite d’être remise en question, et ne pas hésiter à tester plusieurs approches avant de trancher. Cette posture critique est directement alimentée par les efforts de compréhension : plus on comprend un domaine, plus on est capable d’évaluer la qualité de ce que l’IA propose.

L’IA va vite. Parfois trop vite. Et c’est justement là que réside le piège : il est tentant de prendre ses réponses pour acquises sans chercher à comprendre ce qu’elle dit réellement. Or, prendre le temps de comprendre les notions sur lesquelles on travaille reste indispensable, non pas pour vérifier chaque ligne de code, mais pour être en mesure d’évaluer la pertinence de ce qu’on reçoit, d’identifier quand quelque chose cloche, et de prendre des décisions éclairées plutôt que de simplement exécuter

L’IA, un levier puissant à condition de ne rien prendre pour acquis

Ce stage a démontré qu’avec une formation technique généraliste, de la méthode et un usage réfléchi de l’IA, il est possible de mener à bien un projet qui couvre de nombreuses expertises métier. C’est une réalité nouvelle, et elle ouvre des perspectives considérables

Cette expérience a également mis en lumière une vérité que les discours enthousiastes sur l’IA cachent souvent : l’IA ne remplace pas la compétence, elle l’amplifie. Elle rend accessibles des notions complexes, accélère l’apprentissage, structure le travail et réduit la friction dans de nombreuses tâches. En revanche, elle ne remplace ni le jugement, ni l’expérience, ni la curiosité de celui qui l’utilise

La vraie compétence de demain, ce n’est pas d’exécuter par défaut ce que l’IA recommande pour gagner du temps. C’est de savoir s’en servir comme d’un levier : non pas pour combler ce qu’on ne sait pas faire, mais pour aller plus loin que ce qu’on aurait pu faire seul

Ce retour d’expérience a été rédigé à l’issue d’un stage de césure de six mois chez Nobori Partners, au cours duquel j’ai cadré, développé et mis en production une application interne visant à automatiser un cas d’usage métier. Un projet particulièrement enrichissant, qui m’a amenée à toucher à des domaines très variés : prototypage, développement web, architecture réseau, pratiques DevOps. Tout au long de ces six mois, j’ai bénéficié d’un encadrement de qualité, entre points hebdomadaires avec mon tuteur et disponibilité constante des consultants dès qu’une notion touchait leur domaine. Au-delà du projet, c’est l’ouverture et la bienveillance de l’équipe qui ont marqué cette expérience. Je remercie sincèrement toute l’équipe Nobori pour son accompagnement tout au long de cette aventure.

---

Envie de vivre ce type de projet de bout en bout ? Découvrez nos opportunités de stage et de carrière et la façon dont nous accompagnons la montée en compétence de nos consultants.