Formation no-code et IA : créer une application métier sans coder

Jour 1

1. Le bon besoin

• Ce qu’une application légère règle bien : suivi, demandes, réservations, inventaires, contrôles.
• Ce qu’elle ne règle pas : comptabilité, paie, métiers réglementés, gros volumes.
• Ce que coûte une application abandonnée au bout de six mois.
• Pratique : qualification de son besoin, décision argumentée de poursuivre.

2. Décrire avant de construire

• Le processus réel, étape par étape, avec ses exceptions.
• Qui saisit, qui consulte, qui valide, qui est notifié.
• Faire reformuler et challenger son cahier des charges par l’IA.
• Pratique : cahier des charges court et complet de son application.

3. Modéliser ses données

• Entités, champs, relations : la notion de base, sans jargon.
• Les erreurs de modélisation qui coûtent cher trois mois plus tard.
• Reprendre l’existant : importer et nettoyer un tableur.
• Pratique : modèle de données construit et import des données existantes.

4. Choisir sa plateforme

• Les familles d’outils sans code et ce qui les distingue vraiment.
• Coût à l’usage, hébergement des données, export, réversibilité.
• La question qu’on oublie : que se passe-t-il si l’éditeur ferme ou triple ses prix.
• Pratique : choix argumenté et première base construite.

Jour 2

5. Les écrans

• Formulaire de saisie, liste filtrable, fiche de détail, tableau de bord.
• Une interface utilisable par quelqu’un qui n’a pas construit l’outil.
• Usage sur mobile, saisie sur le terrain.
• Pratique : construction des écrans de son application.

6. Automatiser et insérer l’IA

• Notifications, relances, changements de statut, documents générés.
• Où l’IA apporte quelque chose : classer, résumer, extraire, rédiger.
• Où elle n’apporte rien et coûte de l’argent.
• Relier l’application à vos autres outils.
• Pratique : deux automatisations, dont une avec appel à une IA.

7. Accès, données et sécurité

• Rôles et permissions : qui voit quoi, qui modifie quoi.
• Données personnelles : ce que l’application doit respecter dès sa conception.
• Sauvegardes et export : la règle à ne jamais négliger.
• Pratique : mise en place des rôles et d’un export complet.

8. Mettre en service, et connaître ses limites

• Tester avec de vrais utilisateurs avant de basculer.
• Accompagner le changement, documenter l’essentiel.
• Les signaux qui annoncent qu’il faudra un développeur : volume, intégrations, règles complexes.
• Qui maintiendra l’application, et ce qui se passe si cette personne part.
• Questions ouvertes et échanges avec le formateur.