En bref : J’ai construit une application de recrutement prête pour la production — frontend React, backend FastAPI, base de données Oracle 23AI, Docker — en moins de 3 heures. Seul. Sans spec. Sans maquettes. Juste une conversation avec un assistant de développement IA appelé IBM Bob. Voici le récit honnête de ce qui s’est passé et ce que ça signifie concrètement pour notre façon de livrer.

Avant de commencer — Accéder à IBM Bob

Tout ce qui est présenté dans cet article a été construit avec IBM watsonx Code Assistant, appelé « Bob » tout au long du texte. Rendez-vous sur bob.ibm.com/trial, inscrivez-vous pour un essai gratuit, téléchargez l’application de bureau (pensez IDE autonome, similaire à VS Code) et authentifiez-vous via le flux de jeton navigateur au premier lancement. Vous codez en moins de 5 minutes.

Le point de départ : un seul prompt, aucun document

Je travaille avec plusieurs équipes de recrutement et je passais mon temps à consolider des données provenant de trois outils différents pour avoir une vue cohérente de mon pipeline. Je voulais quelque chose de centralisé — un seul endroit pour suivre les candidats, les postes, les candidatures et les entretiens, sans jongler entre les systèmes.

J’ai donc ouvert IBM Bob et j’ai écrit ceci :

“Act as a senior Solution Architect specialized in HR and Recruiting systems. I want to build a Recruiting App following the best practices of recruiting and the standard recruiting business process. Use SQLite or Oracle 23AI database.”

Pas de billet de travail. Pas de spec. Pas de maquette. Cette seule phrase a lancé une session de 3 heures qui a transformé un besoin interne vague en un outil d’entreprise déployable. Ce qui suit, c’est ce qui s’est réellement passé — le bon, l’inattendu, et ce qu’il faut savoir avant d’essayer vous-même.

Comment la session s’est réellement déroulée

Le stack que Bob a choisi était de qualité enterprise dès le départ : frontend React 18, backend FastAPI, Oracle 23AI comme base de données, Redis pour la mise en cache, Docker Compose pour l’infrastructure. Pas un jouet — quelque chose qui pouvait réellement tourner dans un environnement de consultation. Je n’avais rien spécifié de tout ça. Bob l’a déduit du prompt.

Phase 1 — L’architecture avant le code (15 min)

La première réponse de Bob n’était pas du code. C’était une proposition d’architecture.

Avant d’écrire une seule ligne, il a posé l’ensemble du design système : le stack (React 18, FastAPI, Oracle 23AI, Redis, Docker Compose), le modèle de données central (quatre entités — Candidats, Postes, Candidatures, Entretiens — avec leurs relations et leurs champs clés), ainsi que la structure des dossiers et les frontières des modules.

Rien de tout ça n’était dans le prompt. Bob a déduit des choix de niveau enterprise à partir de trois mots : « best practices » et « recruiting ». Il a choisi Oracle 23AI plutôt que SQLite de lui-même, jugeant que c’était la solution adaptée à un système nécessitant l’intégrité relationnelle, des requêtes évolutives et une gestion de données de niveau production. C’est le premier changement de perspective : l’IA ne se contente pas d’écrire du code selon une spec — elle prend des décisions d’architecture et peut les justifier.

Phase 2 — Construction du socle (30 min)

L’architecture validée, Bob a généré la base de code fondamentale en un seul passage.

Schéma de base de données : le DDL Oracle 23AI pour les quatre entités, avec les contraintes de clés étrangères, les index et le typage approprié des champs. Backend : une application FastAPI fonctionnelle avec les endpoints CRUD initiaux, les modèles Pydantic et la configuration Docker. Frontend : un scaffolding React avec le routing, les vues principales et l’intégration API câblée.

Au bout de 30 minutes, l’application tournait. Pas un prototype — une application fonctionnelle et navigable avec de vraies données circulant d’un bout à l’autre. La cohérence était immédiate : conventions de nommage, gestion des erreurs et structures de réponse uniformes sur toutes les couches dès le premier commit.

Phase 3 — Extension des fonctionnalités par l’exemple (45 min)

J’ai dit : « J’ai besoin de pouvoir modifier les Postes, les Candidatures et les Entretiens. » Pas de liste de champs, pas de spec UI. Bob a analysé le pattern de modification existant pour les candidats et l’a reproduit sur les trois autres entités — même logique d’état, même gestion des erreurs, même structure UI. Une seule demande, quatre implémentations cohérentes.

C’est le mécanisme central du vibe coding : montrer à l’IA un pattern fonctionnel et dire « fais la même chose pour X, Y, Z. » La traduction est automatique, et la cohérence est meilleure que ce qu’on obtiendrait en coordonnant une équipe.

Phase 4 — CSV et intégrité des données (35 min)

Deux demandes rapides. Première : « Je ne vois pas l’export et l’import CSV. » Bob a vérifié si les endpoints backend existaient (c’était le cas), puis a branché les boutons frontend, la logique de téléchargement, la gestion des téléversements, les états d’erreur et les notifications de succès. Fait.

Deuxième : j’ai remarqué que le formulaire d’entretien utilisait du texte libre pour la sélection des candidats. Ma demande était à peu près : « Ce champ devrait être une liste déroulante liée à la liste réelle des candidats. » Bob l’a converti en liste déroulante contrôlée, a ajouté le chargement dynamique depuis l’API, a formaté chaque option avec la candidature et le poste associés, et a désactivé le champ en mode édition pour éviter les enregistrements orphelins. Je n’avais spécifié aucun de ces détails d’implémentation. Bob a inféré la préoccupation d’intégrité des données et y a répondu complètement.

Phase 5 — Le formulaire d’entretien (60 min)

La phase la plus exigeante. J’ai partagé un gabarit d’entretien structuré en français — 5 sections, 37 options de modules Oracle, 4 dimensions de compétences notées de 0 à 10, étiquettes bilingues — et j’ai dit « implémente ça. »

Bob a généré le formulaire complet en un seul passage. Validation correcte, modes création et modification, structure complète des étiquettes en français, les 37 options de modules correctement mappées. Ce qui m’a frappé, ce n’était pas la génération de code — c’était la compréhension multi-domaine. Bob gérait simultanément la logique d’état React, les conventions FastAPI, la taxonomie des modules Oracle et la terminologie métier française. Ce n’est pas de l’autocomplétion. C’est une catégorie d’outil différente.

Phase 6 — Documentation et Git (30 min)

Dernière demande : documenter et pousser. Bob a produit un guide de construction et déploiement de 434 lignes, initialisé le dépôt, généré un .gitignore approprié, commité 114 fichiers avec un message significatif et poussé sur GitHub. Le DevOps géré aussi fluidement que le code applicatif.

La comparaison honnête

L’estimation de 2 à 3 semaines n’est pas exagérée. Dans un contexte de consultation, la collecte des exigences seule prend typiquement 2 à 3 jours. Ajoutez les revues de conception, les cycles de développement, les tests d’intégration et les rondes de validation — vous parlez de semaines pour ce que nous avons livré en une après-midi. L’application Oracle Recrutement est un outil interne. La vitesse et l’adaptabilité étaient le bon compromis. Pour un mandat client réglementé avec des specs contractuelles, le calcul est différent.

Ce qui a été livré

Une application de recrutement fonctionnelle : tableau de bord avec KPI en temps réel, grille de candidats avec import/export CSV et analyse de CV, gestion des postes avec suivi de statut et priorité, un pipeline Kanban à 7 étapes, et un module d’entretien structuré avec 37 options de compétences spécifiques Oracle. Le tout appuyé par 32 endpoints API sur Oracle 23AI, 114 fichiers sous contrôle de version, plus de 11 600 lignes de code, et un stack Docker Compose qui démarre en 30 secondes.

5 choses qui m’ont réellement surpris

1. Les prompts vagues fonctionnent — mais le contexte précis compte davantage. Le prompt d’ouverture était intentionnellement flou. Ce qui a rendu la session productive, ce n’était pas la précision de la demande — c’était la précision de la boucle de rétroaction. Quand quelque chose n’était pas correct, je décrivais l’écart clairement. L’IA gérait la traduction en code.

2. La fluidité multi-domaine est le vrai différenciateur. IBM Bob gérait React, FastAPI, Oracle SQL, Docker et la terminologie d’affaires française en contexte simultanément. Cette fluidité simultanée sur plusieurs domaines est ce qui distingue les assistants de développement IA modernes de la recherche et de l’autocomplétion.

3. La cohérence est gratuite. Quand j’ai demandé la fonctionnalité de modification sur trois entités, Bob a appliqué le pattern identique — même logique d’état, même gestion des erreurs, même structure UI — sans qu’on lui dise de le faire. Dans une équipe, ça exige des guides de style, des revues de code et de la coordination. Avec l’IA, ça se produit tout seul.

4. Il faut toujours assumer les décisions de jugement. J’ai laissé Bob gérer la syntaxe, la conception des API et les requêtes de base de données. J’ai personnellement validé la logique métier, les règles d’intégrité des données et tout ce qui avait des implications de sécurité. Cette division n’est pas optionnelle — c’est ce qui rend le résultat digne de confiance.

5. La promesse de productivité est réelle, mais limitée. Trois heures pour un outil interne sur un stack que je maîtrise. Ce chiffre ne se transfère pas à un environnement client réglementé, une intégration sur système existant ou un système nécessitant une vérification formelle. Connaissez les limites avant de les vendre.

Conclusion

Trois heures. Un développeur. Une IA. Une application de recrutement prête pour la production sur Oracle 23AI, déployée via Docker, documentée et poussée sur GitHub.

Le vibe coding n’est pas un raccourci — c’est un mode de travail différent. Les exigences émergent par la conversation. L’itération est immédiate. La documentation est générée. Le rôle du consultant passe de l’écriture du code à la direction des résultats et à la validation de ce qui revient.

Pour les praticiens Oracle Cloud, l’implication est claire : les compétences qui compteront ne sont pas la connaissance approfondie de la syntaxe. C’est la capacité à cadrer les problèmes avec précision, à valider rigoureusement les résultats de l’IA, et à comprendre suffisamment l’architecture pour savoir quand l’IA se trompe. C’est un type d’expertise différent — et il vaut la peine de le développer maintenant.

Annexe : Chronologie du développement

Ressources : Oracle 23AI Free · FastAPI · React · Dépôt GitHub

Christian Guidibi
Oracle Cloud Practice Lead · Consultant en technologie d’entreprise et IA

Christian dirige des implantations Oracle Cloud et des livraisons assistées par IA dans un contexte de consultation. Il écrit sur l’intersection de l’architecture d’entreprise, des outils IA modernes et de la livraison concrète sur guidibi.com.

The post Vibe Coding avec IBM Bob : Construire une application Oracle de recrutement en 3 heures appeared first on Guidibi.com.