Guide pratique · pour décider avant de dépenser

Créer avec l’IA ou déléguer ?

Name: Créer avec l’IA ou déléguer ?
Brand: Bynilson
Price: 39.00 CHF
Availability: InStock

Décidez quoi construire vous-même, quoi acheter et quoi confier à un développeur — avant d’engager votre budget.

Pour fondatrices et fondateurs sans formation technique, growth marketers, designers, product owners et consultants — qui veulent un résultat pour leur activité, pas une carrière de développeur.

Voir un exemple concret

Paiement unique · accès immédiat, web et PDF · pas de compte à créer · remboursé sur simple demande pendant 14 jours

Une démo qui fonctionne ne suffit pas pour décider si vous pouvez livrer le produit seul. Évaluez le périmètre, les risques, les coûts et les contrôles à prévoir.

Le diagnostic, tel quelSaaS · MVP · criticité normale

Avec trois réponses seulement, il refuse de trancher :

Orientation préliminaire : approche hybride à évaluer. Les données traitées, les droits d’accès et votre capacité à maintenir le produit restent à préciser.

Avec les quatorze réponses et des hypothèses explicites :

Construire le parcours principal avec l’IA, acheter les composants standards et faire vérifier les accès, paiements et procédures de reprise avant un lancement payant.

Faire le diagnostic gratuit avec vos réponses →

01 — Pour quoi

Quatre situations, une même question.

Vous voulez lancer un SaaS
Quelles parties construire avec l’IA, lesquelles acheter toutes faites, lesquelles faire vérifier avant le premier client payant — étape par étape, avec la preuve attendue à chaque fois.
Vous avez reçu un devis
Le lire composant par composant, le comparer à d’autres options sur le même périmètre, et exiger des jalons, des preuves de recette et des comptes à votre nom.
Vous avez un prototype fait avec l’IA
Savoir ce qu’une démo prouve et ce qu’elle ne prouve pas, et quels tests observer avant de laisser entrer de vrais utilisateurs ou de l’argent.
Vous hésitez à sous-traiter
Déléguer sans perdre la main : un brief qui tient sur une page, le coût total — pas seulement le devis —, la passation et ce que le support couvre.

02 — Un exemple réel

Un SaaS B2B, de la validation à l’exploitation.

La matrice complète du cas, sans flou ni extrait tronqué. Elle vaut sous ces hypothèses — et le diagnostic dit ce qui la changerait.

Une personne fondatrice seule, sans formation technique.
Un parcours B2B étroit : une tâche principale pour un type de client.
Des données ordinaires de contact et d’activité, pas de dossiers sensibles ou réglementés.
Une facturation standard via un prestataire de paiement.
Un pilote limité à quelques clients connus.
Pas d’exigence de temps réel strict.
Pas de moteur de décision financière sur mesure.

Recommandation sous ces hypothèses — Hybride

Construire le parcours principal avec l’IA, acheter les composants standards et faire vérifier les accès, paiements et procédures de reprise avant un lancement payant.

Exemple rempli : huit étapes, de la validation à l’exploitation
Étape	Décision / action	Risque principal	Preuve / critère de sortie	Coûts à évaluer
1 Valider	Tester un seul problème payant, y compris en le livrant à la main. Qui fait quoi Fondateur Mener 5 à 10 entretiens, livrer le service à la main à 1 ou 2 clients, demander un engagement (précommande, lettre d’intention). Avec l’IA Préparer le guide d’entretien, résumer les notes, produire une maquette cliquable pour en parler. Spécialiste Aucun à ce stade. Question ouverte Qui paie, combien, et pour quel résultat mesurable ?	Construire des fonctions que personne ne veut.	Utilisateur cible, tâche principale, critères de réussite et preuve de demande écrits.	Recherche, temps du fondateur, prototype.
2 Cadrer	Garder un seul parcours et lister les exclusions. Qui fait quoi Fondateur Écrire la fiche projet, les non-objectifs et 5 à 10 exemples d’acceptation. Avec l’IA Relire le brief, signaler les ambiguïtés, proposer des cas limites. Spécialiste Optionnel : une relecture du périmètre (1 à 2 heures). Question ouverte Quelles demandes des clients du pilote refusez-vous pour l’instant ?	Le périmètre gonfle et les intégrations s’accumulent.	Périmètre écrit et exemples d’acceptation (« quand je fais X, j’obtiens Y »).	Heures de spécification et de design.
3 Choisir les composants	Comparer la réutilisation ou l’achat avec le travail sur mesure. Qui fait quoi Fondateur Lister les composants (connexion, paiement, email, base de données, hébergement) et vérifier export et conditions. Avec l’IA Comparer la documentation des services, résumer limites et prix (à vérifier vous-même). Spécialiste Valider les choix structurants : base de données, connexion, paiement. Question ouverte Que se passe-t-il si un fournisseur augmente ses prix ou ferme ?	Dépendance, mauvaise adéquation, pile technique inutile.	Propriété des données, export et compatibilité d’hébergement vérifiés pour chaque composant.	Mise en place, licences, migration.
4 Construire une tranche verticale	Un résultat utilisateur complet, de bout en bout. Qui fait quoi Fondateur Construire avec un agent de code, une petite tâche à la fois, en lisant chaque changement et en testant le parcours. Avec l’IA Écrire l’interface, les écrans de gestion, les tests de base ; expliquer le code. Spécialiste Revue ponctuelle si le parcours touche aux accès ou à l’argent. Question ouverte Qui sait expliquer ce que fait chaque fichier modifié ?	Une démo soignée avec un parcours cassé.	Parcours réussis ET parcours en échec démontrés (mauvaise saisie, session expirée, paiement refusé).	Temps du fondateur ou du développeur, outils de code.
5 Vérifier identité et accès	Tester la propriété des données et les frontières entre comptes. Qui fait quoi Fondateur Créer deux comptes de test et essayer, à la main, d’ouvrir les données de l’autre. Avec l’IA Écrire les tests de refus d’accès et la liste des routes à vérifier. Spécialiste Revoir les règles d’accès côté serveur et dans la base (ex. RLS) avant les vraies données. Question ouverte Un administrateur doit-il voir tous les comptes ? Qui l’autorise ?	Lire ou modifier les données d’un autre utilisateur.	Les tests de refus entre deux comptes passent (A ne lit ni ne modifie rien de B).	Implémentation, revue, corrections.
6 Brancher la facturation	Paiement et accès vérifiés par le serveur. Qui fait quoi Fondateur Tester en mode test du prestataire : payer, refuser, rembourser, rejouer une notification. Avec l’IA Écrire la vérification de signature des notifications et le traitement idempotent. Spécialiste Revoir le flux de paiement avant le premier paiement réel. Question ouverte Que reçoit un client si le paiement passe mais que l’accès échoue ?	Accès sans avoir payé, ou client payant bloqué.	Tests de succès, d’échec, de notification reçue deux fois et de reprise passés.	Intégration, frais de paiement, support.
7 Piloter prudemment	Un déploiement petit et contrôlé. Qui fait quoi Fondateur Nommer qui répond aux incidents, faire un test de restauration, prévenir les clients du pilote. Avec l’IA Rédiger le runbook d’incident et la procédure de retour arrière. Spécialiste Vérifier sauvegardes, alertes et procédure de reprise. Question ouverte Combien de temps de panne le pilote peut-il supporter ?	Bugs invisibles et personne pour réparer.	Surveillance active, restauration testée, retour arrière essayé, responsable nommé.	Infrastructure, revue, sauvegardes.
8 Exploiter et décider	Mesurer l’usage et maintenir. Qui fait quoi Fondateur Suivre la tâche principale (réalisée ou non), décider : continuer, réduire ou arrêter. Avec l’IA Résumer les retours, préparer les mises à jour de dépendances avec leur diff. Spécialiste Maintenance planifiée ou à la demande, selon l’accord. Question ouverte À partir de quel coût ou de quelle charge arrêtez-vous ou recadrez-vous ?	Charge de support et défauts qui s’accumulent.	Le résultat utilisateur est atteint ; un plan de maintenance est accepté.	Support, maintenance, usage, réserve.

Cocher une ligne n’est pas une preuve technique : la preuve, c’est le test observé (deux comptes, un paiement refusé, une restauration réussie), noté avec sa date.

Ce qui changerait la recommandation

Si vous traitiez des données sensibles → Hybride → Confier à un spécialiste. Confier la conception et la réalisation des parties à risque à un spécialiste ; vous gardez le problème, le périmètre, les exemples d’acceptation et les tests de bout en bout.
Si plusieurs entreprises partageaient le produit → Même approche (hybride), mais : Construire les parties ordinaires avec l’IA ; faire réaliser ou vérifier par un spécialiste les droits d’accès entre organisations avant tout usage réel.
Si une panne coûtait des ventes ou des données → Même approche (hybride), mais : Construire les parties ordinaires avec l’IA ; faire réaliser ou vérifier par un spécialiste la surveillance et la reprise avant tout usage réel.
Si une personne technique rejoignait le projet → Hybride → Construire (vous, avec l’IA). Construire vous-même avec l’IA ; faire relire le flux de paiement et les droits d’accès par une seconde personne avant le premier paiement réel.
Si un logiciel existant couvrait l’essentiel → Hybride → Acheter / configurer l’existant. Acheter et configurer le logiciel existant ; ne construire que ce qui manque vraiment, et seulement après l’avoir utilisé.
Si le budget et le temps étaient très limités → Même approche (hybride), mais : Budget trop serré pour faire vérifier un lancement payant : commencer à la main (facture, accès donné manuellement) avec un prototype construit à l’IA, et ne brancher le paiement en ligne qu’après une revue financée.

Le cas complet, en accès libre : SaaS MVP : construire avec l’IA ou déléguer ?

03 — Un extrait

Chapitre 4 : Évaluer l’IA tâche par tâche, pas par catégorie marketing

La question Pour chaque partie de votre produit, que pouvez-vous raisonnablement confier à un outil d’IA, et quelle preuve devez-vous obtenir avant de lui faire confiance ?

Ne demandez pas « l’IA sait-elle faire un SaaS ? » mais « pour cette tâche, puis-je voir quand le résultat est faux ? ». Les outils actuels produisent vite de l’interface, des écrans de gestion et du code d’intégration courant. Le danger n’est pas ce qu’ils écrivent mal de façon visible : c’est ce qui paraît juste sans l’être — les droits d’accès, les paiements, les modifications de la base de données, la reprise après incident.

Extrait du tableau « tâche par tâche » (4 tâches sur 11)
Tâche	Ce que l’IA fait souvent bien	Ce que vous devez vérifier	La preuve qui compte
Interface (écrans, mise en page)	Produire des pages complètes, cohérentes, adaptées au mobile.	Lisibilité, navigation au clavier, messages d’erreur compréhensibles.	Un utilisateur cible réalise la tâche sans aide ; test sur un vrai téléphone.
Autorisation (savoir ce que chacun a le droit de faire)	Écrire des règles qui semblent correctes.	Que chaque lecture et chaque modification est contrôlée côté serveur ou dans la base.	Avec deux comptes, B reçoit un refus en essayant d’ouvrir ou modifier les données de A.
Paiements	Créer une page de paiement chez un prestataire.	Que l’accès dépend de la confirmation du prestataire, reçue par le serveur.	Tests : succès, refus, notification reçue deux fois, onglet fermé, remboursement.
Reprise après incident	Rédiger une procédure.	Que les sauvegardes existent et se restaurent réellement.	Une restauration réussie sur une copie, chronométrée.

Résultat généré ou preuve ?
Ce que vous avez	Ce que cela vaut
« L’agent dit que c’est corrigé. »	Un résultat généré. Pas une preuve.
« Les tests passent. »	Une preuve partielle — seulement si vous savez ce que les tests vérifient et qu’ils peuvent échouer.
« J’ai essayé avec deux comptes : B reçoit un refus. » (daté)	Une preuve observée.
« Une personne qui n’a pas écrit le code l’a relu et a essayé de le contourner. »	Une preuve indépendante — la plus forte.

Dans le guide : les 11 tâches, l’exemple travaillé d’un prototype qui « marchait », la grille à remplir pour votre projet, les signaux d’alerte et les sources datées.

Une fiche projet remplie

Exemple illustratif — personne et chiffres fictifs

Utilisateur: L’assistante administrative d’une fiduciaire de 3 à 8 personnes.
Tâche pénible aujourd’hui: Relancer les factures impayées des clients de la fiduciaire : un tableur, des emails copiés à la main, 3 à 4 heures par semaine, des oublis.
Résultat attendu: Les relances partent au bon moment, avec le bon ton ; elle voit en 2 minutes ce qui a été envoyé et ce qui a été payé.
Preuve de disposition à payer: 2 fiduciaires sur 6 interrogées acceptent un pilote payant à CHF 49 par mois ; aucune n’a encore payé.
Périmètre (première version): Importer les factures ouvertes, choisir un modèle de relance, voir l’historique. Rien d’autre.
Non-objectifs: Pas de comptabilité, pas d’application mobile, pas de plusieurs utilisateurs par fiduciaire.
Alternatives regardées: Faire les relances à la main pour les 2 pilotes pendant un mois ; deux logiciels de facturation du marché couvrent les rappels mais pas les modèles par client.
Diagnostic: Hybride (règle R9) — construire le parcours avec l’IA, acheter connexion et paiement, faire vérifier accès, paiement et reprise avant le premier client payant.
Trois prochaines actions: 1. Livrer les relances à la main aux 2 pilotes. 2. Écrire 8 exemples d’acceptation. 3. Demander deux propositions de revue sur le même brief.

04 — Le contenu

Onze chapitres, chacun dans le même ordre.

La question, la réponse et ses limites, un exemple travaillé, les actions avec le résultat attendu, un outil réutilisable, les signaux d’alerte, quand demander de l’aide, les sources datées. Chemin court : environ une heure. Lecture complète : environ 175 minutes.

1. Décrire le problème avant de choisir les outilsQui a le problème, ce qu’il fait aujourd’hui, le résultat attendu, la preuve qu’il paiera, ce que la première version fait et ne fait pas.
2. Comprendre ce que « fonctionne » veut direSix niveaux, de la démonstration à l’exploitation : ce que chacun exige comme preuves, propriété et maintenance.
3. Construire, acheter, déléguer — ou combinerComparer les quatre approches sur le même périmètre, avec des règles explicites plutôt qu’une intuition.
4. Évaluer l’IA tâche par tâche, pas par catégorie marketingInterface, données, intégrations, accès, paiements, migrations, tests, mise en ligne, reprise, maintenance : ce que l’IA fait bien, ce que vous devez vérifier, la preuve qui compte.
5. Le vocabulaire technique minimumOnze mots pour suivre une conversation technique, poser les bonnes questions et repérer où une erreur peut se cacher.
6. CLI, éditeur de code, interface web et agents de codeQuand le terminal aide vraiment, quand il est inutile, et un premier exercice sûr avec un agent de code.
7. GitHub et MCP, sans complexité inutileCe que sont Git, GitHub et une connexion MCP, quand MCP ne sert à rien, et une connexion en lecture seule à un seul dépôt.
8. Estimer le coût total et savoir quand s’arrêterSéparer l’argent dépensé du temps consommé, comparer les approches sur le même périmètre, et écrire les règles d’arrêt avant de commencer.
9. Engager et piloter un développeur intelligemmentAcheter un résultat vérifiable : un brief, des jalons courts, des preuves, la propriété de tout à votre nom et une passation prévue.
10. Mettre en ligne, vérifier, maintenirHuit vérifications observées avant que de vraies personnes utilisent et paient le produit, un exercice d’incident, et une personne responsable ensuite.
11. Les prochaines décisions de votre projetTransformer vos réponses en un plan borné, des questions ouvertes et trois actions pour cette semaine.

Page d’un chapitre du guide : la question, la réponse encadrée et ses limites — Un chapitre : la question, la réponse et ses limites, puis l’essentiel.

Fiche projet enregistrée avec la recommandation du diagnostic et les trois prochaines actions — La fiche projet et sa recommandation, enregistrées dans votre accès.

Modèle de coûts : saisie par approche et scénario, enveloppe cash et coût économique — Boîte à outils : le modèle de coûts, cash et coût économique.

05 — Les formules

Le guide, ou le guide et ses outils.

Deux formules au choix, paiement unique. La boîte à outils contient tout le guide : ce n’est pas un supplément à ajouter aux 39 CHF.

Guide

CHF 39 paiement unique

Le guide complet : 11 chapitres, en ligne et en PDF
6 cas travaillés, du SaaS au projet à données sensibles
Votre fiche projet en ligne, enregistrée dans votre accès
La matrice d’auto-évaluation construire / acheter / hybride / déléguer
La checklist essentielle avant lancement

Guide + boîte à outils

CHF 99 paiement unique, guide compris

Tout le guide
Le modèle de coûts éditable : 4 approches, 3 scénarios, 90 jours et 12 mois
Le brief projet d’une page, avec périmètre et non-objectifs
La matrice composant par composant (CSV)
Le brief de passation développeur et le modèle d’acceptation de jalon
La checklist de tests : connexion, accès, paiements, reprise
Le runbook incident / retour arrière et l’inventaire de propriété
Le brief de tâche IA, le prompt de revue de changement, la fiche de débogage
Le rapport de décision détaillé, exportable (Markdown, JSON)

Formats: Lecture web · PDF · Markdown · CSV · JSON — rien d’autre n’est promis.
Accès: Accès en ligne sans limite de durée pour la version achetée, par lien de connexion envoyé à l’adresse du paiement. Pas de compte à créer, pas de mot de passe.
Mises à jour: Les corrections et mises à jour de la version 1 sont incluses. Une éventuelle version 2 entièrement nouvelle serait annoncée à part ; elle ne retirerait rien à ce que vous avez acheté.
Remboursement: Si le guide ne vous est pas utile, écrivez dans les 14 jours suivant l’achat : remboursement intégral, sans justification. L’accès lié à ce paiement est alors désactivé ; vos autres achats ne sont pas touchés.
Support: Une question sur le contenu ou un problème d’accès : danilson.daveigaramos.pro@gmail.com. Réponse sous 3 jours ouvrés. Le support porte sur le guide et l’accès, pas sur votre projet (voir la revue de projet).
Ce que ce n’est pas: Ni une formation pour devenir développeur, ni un audit de sécurité, ni un avis juridique, ni une promesse de cloner une plateforme complexe en un week-end.

Déjà acheté ? Recevoir mon lien de connexion. Conditions : vente · confidentialité.

06 — Aide humaine

Si vous voulez un avis, à part.

Revue de projet

Périmètre fixe proposé · CHF 299 · paiement en ligne désactivé

Une relecture humaine de votre brief, une recommandation argumentée, les risques principaux, les hypothèses de budget et les prochaines étapes. Pas un audit de code, pas une certification.

Voir le périmètre et demander une revue →

Développement

Sur devis, après un échange

Si le diagnostic recommande de déléguer et que vous voulez en parler avec l’auteur, la demande de projet passe par le formulaire habituel.

Décrire un projet →

07 — L’auteur

Écrit par quelqu’un qui construit et exploite des produits.

Danilson Ramos est un ingénieur produit indépendant basé à Zürich, en Suisse. Il conçoit, construit et exploite des logiciels de production — SaaS, logiciels sur mesure, produits intégrant l’IA — en particulier des systèmes à règles, à workflows et à paiements, de l’architecture produit et du modèle de données jusqu’aux paiements, aux emails, au déploiement et à l’observabilité. Il est le créateur d’Atamatax, Horvera, Wabiro, Vellaci et SponsorsMetrics, et l’auteur des articles techniques de bynilson.ch. Bynilson est le nom de sa pratique.

Ses produits et leur état réel sont documentés sur sa page. Il propose aussi des services (revue, développement) : le guide dit explicitement quand vous n’en avez pas besoin.

Pour aller plus loin, en accès libre : les limites de l’IA pour développer un produit web.

08 — Questions

Questions honnêtes.

Faut-il savoir coder ?

Non. Le guide est écrit pour des fondateurs, marketeurs, designers, product owners et consultants sans formation technique. Le vocabulaire nécessaire est expliqué dans son contexte, avec ce qu’il change concrètement. Les chapitres sur le terminal et GitHub sont utiles si vous voulez toucher au code, facultatifs sinon.

Pourquoi payer alors qu’une IA ou des articles gratuits peuvent répondre ?

Ils peuvent donner des réponses utiles — et le diagnostic de cette page est gratuit. Le guide apporte autre chose : un processus organisé et réutilisable, les mêmes règles publiées pour chaque décision, des cas travaillés, les preuves à exiger avant d’accepter un travail, des modèles éditables et des sources datées. Jugez sur l’extrait et l’exemple ci-dessus.

Quels formats ?

Lecture web, PDF, Markdown, CSV, JSON. Le PDF est généré depuis le même contenu que la lecture web. Pas de fichiers Word ou Excel natifs : les CSV s’ouvrent dans tous les tableurs.

Comment accède-t-on au guide ?

Après le paiement, la page de confirmation ouvre votre accès, et un email vous envoie un lien personnel. Ensuite, vous demandez un lien de connexion avec l’adresse du paiement. Pas de compte à créer, pas de mot de passe.

Et les mises à jour ?

Les corrections et mises à jour de la version 1 sont incluses. Une éventuelle version 2 entièrement nouvelle serait annoncée à part ; elle ne retirerait rien à ce que vous avez acheté.

Et si le guide ne me sert pas ?

Si le guide ne vous est pas utile, écrivez dans les 14 jours suivant l’achat : remboursement intégral, sans justification. L’accès lié à ce paiement est alors désactivé ; vos autres achats ne sont pas touchés.

Quel support ?

Une question sur le contenu ou un problème d’accès : danilson.daveigaramos.pro@gmail.com. Réponse sous 3 jours ouvrés. Le support porte sur le guide et l’accès, pas sur votre projet (voir la revue de projet).

Une revue humaine de mon projet est-elle incluse ?

Non. La revue de projet est une offre séparée (périmètre fixe proposé, CHF 299), demandée par formulaire ; le paiement en ligne n’est pas ouvert pour elle. Elle n’est jamais nécessaire pour utiliser le guide.

Quelles sont les limites du guide ?

C’est un cadre de décision éditorial, pas un audit de sécurité, pas une certification, pas un avis juridique. Les outils changent : chaque fait externe est daté. Le diagnostic ne voit que vos réponses — ni votre code, ni vos données, ni vos contrats.

Le diagnostic pousse-t-il vers vos services ?

Non. Ses règles sont publiées et ne connaissent pas mes offres. Il recommande souvent d’acheter un logiciel existant, et le guide liste explicitement les cas où aucun prestataire n’est nécessaire.

Mes réponses sont-elles enregistrées ?

Le diagnostic gratuit garde vos réponses dans votre navigateur. Elles ne sont enregistrées sur votre accès que si vous les sauvegardez dans votre fiche projet, après achat. La mesure d’audience ne reçoit aucune réponse ni aucun texte.

Quelle différence avec Build School ?

Build School apprend à construire et vérifier un premier produit avec un agent de code. Ce guide aide à décider s’il faut le construire, l’acheter ou le confier. Ce sont deux produits distincts ; les accès Build School existants ne changent pas.

Décidez avant de dépenser.

Faire d’abord le diagnostic gratuit