Hissein Mahamat Abdoulaye

Méthode

Une sortie d'IA peut être impeccable et fausse.

Mon travail est de le voir avant la livraison. Voici comment, en trois temps, avec des cas réels.

La règle de transparence

Chaque projet de ce site porte une étiquette qui dit comment il a été produit. Je cadre, je spécifie, je recherche et je vérifie. L'exécution visuelle et une partie du code sont produites par des outils génératifs que je pilote. Un portfolio qui laisserait croire à une exécution manuelle qui n'existe pas ne tiendrait pas au premier entretien technique.

Les cinq phases

1 · Cadrage et recherche

Poser le problème avant l'outil

Un diagnostic ou une session de cadrage précèdent toute maquette. Ce qui ne se discute pas (palette, mots interdits, un seul bouton principal par section) est écrit dans un cahier. La recherche est documentaire et précède la génération : sur ATS First, elle a permis de fonder les personas sur des données.

2 · Analyse des tâches

Comprendre ce que l'utilisateur fait

Les tâches sont décrites avant les écrans, avec la méthode K-MADe.

3 · Prototypage et vérification

Je teste moi-même et je corrige

Maquettes et prototypes sont produits par les outils génératifs sous cahier écrit. Je les essaie, je constate ce qui ne marche pas, je modifie. Ce n'est pas un test utilisateur : mon mémoire dit que sur ATS First les tests formels ont été omis, et ce que cela a coûté.

4 · Implémentation orchestrée

Écrire ce que l'outil doit faire

Sur Altinum, un cahier de construction et un protocole de références cadrent chaque séance. Un convertisseur produit les sept pages depuis les maquettes : on corrige la source, pas la page.

5 · Rétrospective

Relire, mesurer, écrire la limite

Une suite de 43 tests d'interactions, des captures à trois largeurs (1440, 820 et 390 px) et mon contrôle page par page avant la suite. Chaque projet se termine par sa limite écrite.

Ce que la vérification a trouvé

Trois cas où l'outil avait tort ou allait trop loin.

  • Bizcard. L'outil a ajouté une fonction que personne n'avait demandée. Un humain a décidé de la garder.
  • ATS First. Le test utilisateur a été sauté. Deux défauts ont été découverts après la livraison.
  • Annuaire IAS. La base de données a été coupée après 90 jours, faute d'inventaire des dépendances.

Ce que je vérifie à chaque fois : ce qui a été produit, ce que l'outil déclare avoir produit, et l'écart entre les deux.

Mes points de contrôle

  • Avant de produire. Comprendre d'abord : la recherche documentaire précède les maquettes, même quand l'outil permet de générer tout de suite.
  • Le contrat donné à l'agent. Quand je le modifie, je change d'abord l'exemple concret, parce que l'agent suit l'exemple plus fidèlement que la définition.
  • Après avoir produit. Je confronte la sortie au contrat d'entrée, ligne à ligne, et pas seulement sa conformité de forme.
  • La durabilité. J'inventorie ce qui cesserait de fonctionner si un service tiers changeait ses conditions.
  • Ce que la loi exige. Les modèles omettent souvent mentions légales, politique de confidentialité et gestion des rôles : je les vérifie à chaque projet.

Limite : je n'ai pas tenu de journal de décisions au fil de l'eau. Plusieurs choix ont été reconstitués après coup, donc ne sont plus datables avec précision.

Environnement de travail

Orchestration IA

  • Claude Code
  • Lovable
  • Google AI Studio
  • Stitch
  • Manus
  • Higgsfield

Recherche

  • Gemini Notebook
  • Perplexity
  • Reddit

Conception

  • Figma
  • Canva
  • Suite Adobe

Code et déploiement

  • Visual Studio
  • Antigravity IDE
  • GitHub
  • Vercel
  • Render
  • Supabase
  • Google Cloud

CMS et e-commerce

  • WordPress
  • Elementor
  • WooCommerce

Organisation

  • Notion
  • Google Drive

Limite : ces constats viennent de quatre terrains de recherche menés pour un mémoire, sans client ni utilisateurs réels.

Ces terrains sont analysés dans mon mémoire de Master 2 sur l'IA générative dans les systèmes de conception numérique agile, soutenu en septembre 2026 à l'UPHF.

Voir les projets