Transcription

• Speaker #0

  Et bonjour à tous, bienvenue dans ce nouvel épisode de Beyond the Brackets. Et aujourd'hui, on est avec Adrien, comme d'habitude.

• Speaker #1

  Eh oui, bonjour Loïc. On se retrouve aujourd'hui, encore une fois, dans un cadre magnifique.

• Speaker #0

  Le cadre est bien meilleur. On a le droit à ce paysage champêtre, la campagne, un peu de soleil. Il fait tellement chaud là, ça fait du bien.

• Speaker #1

  On est sortis de notre cave, finalement.

• Speaker #0

  C'est vraiment le cas de le dire. Et aujourd'hui, on sort de notre cave. On s'est un peu airé l'esprit, on s'est dit mais quand on lance une application, ça coûte cher quand même. Et pourquoi ça coûte cher ? C'est la question à laquelle on va essayer de répondre aujourd'hui. Si j'arrive à faire une phrase française. Est-ce que tu es ready pour ce podcast ? Est-ce qu'on y va ?

• Speaker #1

  Le sujet est passionnant. On est souvent confronté à des questions comme celle-là, donc je pense qu'elles vont forcément intéresser nos auditeurs. Donc je suis ready.

• Speaker #0

  Ok, let's go ! Je te propose de nous donner un peu, toi, de ton point de vue, quand tu as, là, ça fait quand même quelques années que tu devs chez Beyond the Brackets, on a eu Accelerio qui est vraiment une startup qu'on a travaillée de zéro. Quels sont pour toi, quand on lance un produit technologique, un peu les steps à regarder ?

• Speaker #1

  Je dirais que l'une des choses les plus importantes, je vais dire, c'est de construire son produit. étape par étape et la première chose que je dirais c'est de identifier les points essentiels de son application à mettre en oeuvre dès le début quand on veut créer son application et une fois qu'on les a identifiés avant même de se lancer dans la création du produit ce qui est intéressant c'est d'aller tester son marché justement sur ces paint points et derrière quand on passe à la mise en oeuvre du projet de ne pas oublier ces paint points et de se dire je veux une application parfaite et de commencer à mettre en place le plus important

• Speaker #0

  ça je pense que déjà pour commencer je sais pas ce que tu en penses on est sur un bon début ouais c'est la base c'est déjà pour quel problème vous allez résoudre avec votre entreprise lister, comprendre et ça attaque c'est le plus important et faut pas se cacher faut aussi prévoir un peu les coûts potentiels que ça peut avoir une petite idée d'une roadmap par exemple parce que tu disais là qu'il faut identifier tous les pain points mais vous allez pas les résoudre à la V1 de votre application. Vous avez peut-être un ou deux que vous avez identifiés, ça va fonctionner, peut-être les plus importants, pour ensuite attaquer le reste de vos pain points et le reste de l'application.

• Speaker #1

  Tu parlais des coûts, d'ailleurs c'est intéressant, parce que je pense qu'une fois qu'on a réussi à identifier les plus gros points de son projet, on peut plus facilement se demander combien ça va coûter. Si on n'a pas commencé à identifier... Souvent on va dire ah ouais je veux une application qui ressemble à ça, avec un bout de cette autre application, je veux faire un mélange, je sais pas. Et donc souvent de quantifier, d'être capable même d'aller peut-être voir des gens comme nous pour leur demander un budget, pour nous c'est pas facile de savoir. Alors qu'une fois qu'on identifiait les gros points, c'est beaucoup plus facile de quantifier, de poser un devis simplement.

• Speaker #0

  Oui, c'est très important parce que quand vous nous dites, quand vous venez nous voir en disant je veux recréer Instagram, je veux recréer Facebook, c'est quand même des milliers et des milliers d'ingénieurs qu'il y a derrière. Donc, ils ont travaillé depuis des années là-dessus. Donc, il y a énormément de fonctionnalités qui ont été créées. Et peut-être que vous, vous n'avez pas besoin de toutes ces fonctionnalités. Vous voulez résoudre deux, trois pain points là-dedans. Et donc, nous, limite, ça va nous tendre à faire un plus gros devis parce qu'on va dire bon, il faut prévoir ça, il faut prévoir ça, il faut prévoir ça. Alors que pour vous, ce n'est pas très important. Donc c'est vrai que c'est important de préparer son scope, son scope of work, j'ai envie de dire, si on peut parler anglais, dans ce genre de projet. Et puis, il y a une bonne pratique que moi j'adore en tout cas quand on vient me demander de faire un devis sur un projet et tout, c'est d'arriver avec des maquettes. Parce que les maquettes, ça va vous forcer à travailler ce côté de qu'est-ce que je veux dans l'application. le nombre d'écrans, que ce soit une application web ou une application mobile, et les différentes fonctionnalités vont apparaître quand vous allez faire les maquettes. Donc nous, quand vous arrivez là-dessus, avec des maquettes chez Beyond Bracket, on peut se dire, bon, ok, donc là, il faut prévoir une page de login, il faut prévoir la gestion du paiement, il faut prévoir la gestion d'un profil utilisateur où il faut pouvoir uploader une photo, etc. Nous, on redécortique tout ça en fonctionnalités. Et on sait précisément ce que vous voulez du coup, puisque vous avez fait cette réflexion sur les maquettes.

• Speaker #1

  Oui, c'est vrai que c'est même essentiel, je pense, de faire des maquettes. En tout cas, pour bien commencer son projet, comme tu le dis, je pense que c'est vraiment un très bon point.

• Speaker #0

  Par notre propre expérience, quand il n'y a pas de maquette, souvent ça part un peu dans tous les sens. Au dev, on se perd un peu, parce qu'il faut qu'on imagine des fonctionnalités. Et au niveau du client, on ne fait pas un one-shot direct, ça marche.

• Speaker #1

  Oui, parce qu'il y a toujours une idée qui n'a pas été exprimée dès le début, ou même des idées qui sont... qui sont pensés après le début du projet, on se dit ah oui ça serait bien de faire ça et là on commence à rentrer dans une espèce de boucle de ah mais faut rajouter ça,

• Speaker #0

  ah mais non faisons enlever ça et puis là c'est ça part un peu en cacahuètes c'est là on perd du temps oui oui oui et on reviendra plus tard mais quand on perd du temps ça rallonge les frais exactement les coûts de développement donc vaut mieux tout prévoir dès le début et c'est vrai qu'aujourd'hui j'ai mis en deux braquettes on a rajouté un peu cette corde à notre arc autour de l'UiUX, comme ça s'appelle, de faire des maquettes. C'est l'expérience utilisateur et le design de l'application pour justement, si vous n'arrivez pas avec des maquettes, on va prendre le temps, quelqu'un qui va être dédié pour vous, pour faire des maquettes, vous écouter, comprendre ce que vous essayez de faire. Et c'est plus rapide d'itérer sur des maquettes que sur du code informatique.

• Speaker #1

  Totalement. C'est vrai que c'est en fait un plan qu'il faut mettre en place dès le début. Et je pense qu'avec l'expérience, même... On a déjà parlé un peu de créer son projet au début des podcasts. Je pense qu'on n'avait peut-être pas appuyé assez là-dessus, mais maintenant, avec un peu plus de recul, un peu plus d'expérience, c'est vrai que c'est important, c'est même essentiel qu'on dise que faire des maquettes, c'est beaucoup plus simple que de se lancer tête baissée, corps et âme, dans un projet qu'on n'a pas bien identifié, qu'on n'a pas mis des barrières précises.

• Speaker #0

  Oui, clairement. Et même nous, moi, au niveau côté commercial. je mets maintenant dans le devis maquette 10 jours comme ça ça prévoit de créer maquette et le temps des réunions moelleur par si externe depuis au moins il n'y a pas de surprise pour le client aussi quoi oui c'est ça il sait pourquoi il sait pourquoi il va payer donc c'est plutôt cool et les maquettes si on s'en revient un peu sur ce coup ça va dépendre des agences et l'expérience de la personne comme d'habitude mais mais aujourd'hui on peut même accélérer un peu grâce à l'IA on peut mettre des images sympas rapidement comme on en parle souvent mais on se retrouve sur un coût ça peut être quand même assez élevé ça peut monter à 3 à 4 mille euros de faire des maquettes on a quand même quelque chose de bien consistant à ce moment là en tout cas nous c'est plus les prix qu'on opère chez Beyond après il faut aller faire des devises dans les autres agences pour voir ce que ça implique et ce qui est inclus là dedans On attaque le développement ?

• Speaker #1

  On attaque le développement.

• Speaker #0

  Le cœur de notre métier, ce qu'on fait tous les jours, ce qu'on faisait il y a deux minutes avant de tourner ce podcast. Le développement, comme vous le savez si vous écoutez un peu ça, c'est un peu le plus gros budget à allouer quand on lance un produit comme ça tech. Parce qu'il y a le coût des personnes humaines qui vont travailler chaque jour dessus. C'est souvent ça qui coûte le plus cher. Mais il ne faut surtout pas oublier les coûts cachés. on va avoir les API que vous utilisez. Par exemple, une API, c'est ce qui va permettre aux développeurs de faire la gestion du paiement. Si par exemple, on était Stripe, Stripe, au niveau de ses coûts, ça va être 25 centimes fixes et un pourcentage sur chaque paiement qui allait passer sur le site Internet.

• Speaker #1

  Oui, parce que ce qu'il faut quand même bien expliquer, c'est que quand vous allez monter votre produit, vous n'allez pas pouvoir recréer la... la totalité des fonctionnalités, comme par exemple, tu pouvais donner le problème du paiement. Parce qu'en fait, si vous vous remettez à créer une plateforme de paiement en ligne pour votre application, si tout le monde devait recréer une plateforme en ligne de paiement, les projets seraient beaucoup plus chers. Donc, en fait, il y a des boîtes qui se lancent et qui mettent en place des API, comme tu étais en train de l'expliquer. Et donc, forcément, ça a des coûts. Donc, Stripe, c'est un très bon exemple. quand même très souvent dans les produits des achats qui se font sur les plateformes qu'on développe. Ce n'est pas toujours le cas, mais c'est très souvent le cas. On a d'autres exemples d'API qu'on peut utiliser.

• Speaker #0

  Qu'est-ce qu'on utilise souvent ? On peut utiliser Mailjet au niveau des mails. Donc là, on a la chance qu'ils ont quand même une version gratuite assez conséquente, mais on peut rapidement se trouver à payer mensuellement. Si on envoyait plus de 3000 mails par mois, je dis des bêtises, mais ça, ça peut être une API. Ça nous permet d'intégrer tout de suite avec votre code ces fonctionnalités d'emailing, de paiement.

• Speaker #1

  Donc là, typiquement, c'est quelqu'un achète un truc sur votre site. et vous voulez lui envoyer un mail automatique pour lui dire votre commande est partie, Mailjet c'est ce qu'ils vont faire. Je vulgarise un petit peu, parce qu'on n'a pas forcément la connaissance sur tous les points.

• Speaker #0

  Non mais après il y a d'autres API, par exemple si vous venez avec l'idée de faire un streaming vidéo, nous on va peut-être pas ré-encoder tout un codec, je parle technique, mais tout un codec de streaming vidéo, d'un flux vidéo, etc. Donc on va plus s'appuyer sur des API comme MUX, qui aujourd'hui sont un peu leader là-dessus dans le marché, mais qui ont un certain coût au nombre de vues, au nombre de secondes uploadées de vidéos, etc. Donc ça demande aussi de faire un business plan en fonction de ces API.

• Speaker #1

  Oui, exactement. Et donc je disais il y a quelques minutes qu'on ne va pas recréer ce genre de fonctionnalités parce qu'il y a des API qui existent, mais parfois en fait on arrive sur des... sur des features où on peut quand même se poser la question est-ce que j'ai envie de le recréer parce que ça va me coûter peut-être 15000 euros mais l'API comme je vais mettre je sais pas 1500 euros par mois d'API en fait au bout de tant d'années bah en fait je vais me dire ouais mon coup si je peux le supprimer donc est-ce que je ferais pas mieux de directement le recréer moi-même enfin voilà là on arrive sur des questions où il y a des API où On peut se poser la question et justement, quand on construit son projet, qu'on veut construire son produit, c'est une des questions majeures. Parce que Stripe, par exemple, vous n'allez pas le refaire. Ça, c'est une certaine idée. Mais par contre, il y a des points quand même un peu plus tendus. On peut se dire, est-ce que je vais remettre en place ou pas ? Ça, c'est vraiment très important quand on commence son projet.

• Speaker #0

  C'est la gestion du budget. Tu as tout à fait raison. Soit vous payez le développement plus cher, soit vous... Vous payez une API peut-être sur le long terme et ça vous coûtera peut-être plus cher ensuite pour l'enlever et changer la technique. Ça, c'est pas mal. Et pour toutes les startups IA qui se lancent en ce moment, il faut intégrer ChatGPT en API. Pareil, c'est un coût à la requête, etc. Donc, il faut le calculer tout ça et il ne faut pas le laisser de côté. Ce n'est pas anodin de payer des APIs, etc.

• Speaker #1

  C'est vrai qu'on peut vite être surpris par le coût que ça peut représenter.

• Speaker #0

  Dans les autres coûts cachés, on a les serveurs. Parce que ça, on ne le montre pas forcément dans les devis. On fait le devis vraiment du temps de développement humain. Mais les serveurs, ça peut représenter un coût. Après aujourd'hui, c'est quand même beaucoup moins cher qu'à l'époque. C'est beaucoup plus démocratisé, AWS. pour ceux qui acceptent de mettre leurs données sur AWS, proposent pour les startups au moins 1 000 dollars de crédit pour ceux qui se lancent. Donc 1 000 dollars, franchement, si vous n'avez pas un très gros projet, ça vous tient 2-3 ans d'hébergement. Facile.

• Speaker #1

  C'est malin de leur part de faire ça de toute façon.

• Speaker #0

  Comme ça, ça force les développeurs, enfin ça ne force pas les développeurs, mais ça force les décisionnaires à utiliser AWS. Donc les développeurs vont utiliser AWS. Moi, maintenant que j'utilise AWS, je n'ai plus envie de partir parce que c'est trop simple pour nous, une fois qu'on le comprend. Et une fois que tu as toute ton infrate posée, tu as la flemme de la refaire autre part.

• Speaker #1

  Ça, ce n'est pas moi qui vais dire le contraire.

• Speaker #0

  Du côté DevOps, ce n'est pas une tasse de thé. Donc, il faut le prévoir. Dans la majeure partie des cas, un serveur, ça peut vous… Enfin, un serveur. Vous allez avoir plusieurs serveurs sur un projet. Prenons une appli… une appli mobile vous avez votre back-end donc tout ce qui va permettre de lire la base de données pour l'afficher sur votre appli mobile et la base de données c'est vos deux gros serveurs sur une appli mobile et sur une appli web vous allez en avoir trois la base de données le back et le front qui est votre design donc maximum vous avez trois serveurs suivant la ressource que vous utilisez chez aws puisque c'est ce que nous on utilise le plus ça va vous donner différents coûts. Par exemple, je sais que l'appreneur chez AWS coûte un peu plus cher que si on prenait un EC2 classique ou un Amplify, pour ceux qui connaissent. Donc voilà, et après c'est à la délicatesse de votre développeur de choisir, suivant vos coûts, le bon serveur pour ce que vous voulez faire, évidemment. Mais, par exemple, nous, souvent c'est peut-être 70$, 100$ par mois.

• Speaker #1

  Ça reste des coûts raisonnables mais qu'il faut quand même connaître.

• Speaker #0

  C'est ça.

• Speaker #1

  Souvent quand on lance un produit on roule pas sur l'or donc c'est important même de connaître ses coûts forcément.

• Speaker #0

  Faut le prévoir. Et une fois qu'on a fait l'application, on a mis sur les serveurs, on a intégré toutes les API, qu'est-ce qu'on va se faire juste après, avant la mise en prod ?

• Speaker #1

  Avant la mise en prod ? Les tests ?

• Speaker #0

  Les tests. Je te laisse en parler étant donné que tu as fait un travail de QA chez Rakuten.

• Speaker #1

  C'est vrai, c'est vrai. J'en ai déjà un peu parlé je crois mais bon. Oui, non, c'est quelque chose qui est beaucoup mis de côté les tests, même par nous d'ailleurs. En fait, c'est la délicatesse du client, j'ai envie de dire, mais de payer des tests en plus, ce n'est pas souvent quelque chose qu'on a envie de faire. Mais c'est vrai que quand on a un produit qui est en ligne, ça peut être même une application mobile ou quoi que ce soit, le fait d'avoir des tests qui vont venir vous assurer que la mise à jour que vous venez de mettre en ligne n'a pas cassé les pans principaux de votre application mobile ou de votre site internet, c'est quelque chose qui n'est pas essentiel. Parce que quand vous commencez, vous pouvez le faire à la main. Vous pouvez vous dire, là il y a une nouvelle mise à jour, je vais vérifier. Ah oui, ça, ça marche, ça marche. Mais en fait, quand vous allez commencer à scaler votre application, à avoir des utilisateurs, et que vous allez avoir de plus en plus de petits bugs qui vont arriver, qui vont être presque indétectables, En fait, si à chaque fois que vous faites une nouvelle feature, vous vous dites, ah bah tiens, je mets en place en parallèle des tests, vous vous assurez déjà de ne pas oublier toutes ces features, parce que même si on connaît bien son produit, on ne peut pas toujours le tester à la main à chaque fois au bout d'un moment. Et donc, forcément, les tests, c'est un gage de qualité, simplement.

• Speaker #0

  C'est totalement ça. Aujourd'hui, comme tu le disais, nous, on ne le fait pas par manque de budget, surtout sur nos clients. parce que c'est faux remobiliser un développeur ou au moins quelqu'un qui comprend un peu la technique pour le faire donc ça redemande de l'argent mais j'ai pas grand chose à rajouter sur ce que tu dis en plus t'es un expert QA sachant qu'il y a quand même une petite guerre QA dev forcément parce que le dev il fait quand même ses tests nous on teste quand même voir si ça marche ce qu'on fait on développe pas à l'aveugle mais on pense à chaque fois avoir fait le tour des potentiels bugs Et évidemment, il y a quelqu'un qui repasse, qui n'a pas codé, qui fait Ah, là, il y a une erreur. Et du coup, tu es très malheureux.

• Speaker #1

  C'est clair. Et puis en plus, je voudrais rajouter un petit point là-dessus, c'est que comme tu le disais tout à l'heure au niveau des coûts, le développement d'une application, c'est ce qui coûte le plus cher. Donc en fait, si vous arrivez et que vous vous dites Ok, ça, c'est ce qui me coûte le plus cher, mais en plus de ça, je vais avoir un coût pour faire des tests. sur l'application, ça peut être compliqué d'avaler la pilule. Parce que t'as envie de te dire pourquoi je vais faire des tests ? Le mec, je le paye déjà hyper cher, il va me faire un truc qui va marcher sans tester. Mais bon, c'est pas vraiment... C'est pas aussi simple que ça. C'est compliqué de se dire... Si vous voulez, quand on est en train de développer l'application, le client, il voit son application qui est en train de monter, qui est en train de se construire. Ah oui, vous avez rajouté ça. Donc il y a une espèce de satisfaction. Mais si demain, on se met à faire pendant deux semaines une création de test, il y a... il n'y a rien qui va se passer. L'application, elle va rester la même, juste les thèses vont tourner et puis vous dire que ça fonctionne. Mais bon, il n'y a pas vraiment de... C'est compliqué de vendre ça, d'expliquer vraiment que c'est important.

• Speaker #0

  C'est moins gratifiant, en fait. Que ce soit pour le client ou même pour les devs. Et c'est pour ça aussi qu'on essaye de pallier ça dans le sens où, dans le Trello, souvent quand on rajoute une feature ou qu'on a affiné un ticket, on le met, on le mit. On le met dans to be validated ou à valider pour que le client teste. Nous, on essaye de push un maximum sur les environnements test des clients. Il teste et il peut nous faire ses retours directs. Déjà, il y a déjà quelqu'un qui vient contrôler un peu la qualité. C'est un peu un contrôle qualité. Du dev qui a été fait et on peut tout de suite résoudre un bug qui arrive. Et je crois que la transition va être exceptionnelle avec le prochain point. Parce que quand il y a un bug qui arrive, mais qu'on a fini la prestation, comment on fait ?

• Speaker #1

  on met en place un contrat de maintenance.

• Speaker #0

  Tout à fait. Et c'est hyper important. Il ne faut surtout pas oublier ça. Après, si ça se passe bien avec le dev que vous avez, il faut faire un contrat de maintenance avec lui. Plus compliqué si vous allez voir une autre agence pour une maintenance d'une appli qu'ils n'ont pas faite, forcément. Mais en tout cas, le contrat de maintenance est hyper important parce que ce n'est pas parce que votre développement est terminé que vous n'aurez aucun problème sur votre application. jusqu'à la fin des temps et même s'il n'y a pas eu de bug à la sortie il y aura des mises à jour à faire et quand il y a des mises à jour souvent il faut refaire un peu un bout de code ou fixe enfin résoudre quelques bugs que ça a engendré donc la maintenance est importante parce qu'il ya les serveurs si les serveurs cassent faut que quelqu'un les remonte etc si vous avez des petits bugs qui arrivent de vos clients il faut quelqu'un qui les corrige si vous voulez faire une petite mise à jour d'un petit design d'un petit bouton d'une petite icône c'est cool d'avoir un contrat de maintenance que vous mettez ça là dessus vous n'êtes pas obligé de repartir sur un contrat de prestations en entier donc c'est plutôt C'est plutôt important.

• Speaker #1

  Totalement, puis en plus, ça permet de garder un contact avec l'équipe qui a construit votre application si vous continuez avec la même équipe pour le contrat de maintenance. Et puis, ça permet derrière de mettre en place des V2, des V3 de votre application, parce que la maintenance, elle va aussi forcément amener à ces problèmes qui ne vont pas pouvoir être résolus parce qu'il faut refaire un pan de l'application. Ça me fait un peu penser à moi d'il y a quelques années, quand j'ai commencé un peu mes études. C'est un truc, je me posais une question. C'est un peu bête maintenant, mais je me disais, par exemple, chez Apple ou chez Microsoft, ils ont fait leurs produits. Et pourquoi il y a toujours autant de développeurs dans cette boîte ? Ah oui ! C'est-à-dire que le truc, il est fait, quoi.

• Speaker #0

  Oui, c'est terminé.

• Speaker #1

  Mais tu vois, même moi, j'ai bossé chez Rakuten, qui est un truc qui... moins vite en termes de développement. Apple, ils font des mises à jour tous les jours, mais tu prends Rakuten, par exemple, leur produit en soi, j'y étais il y a deux ans, bon, oui, ils ont rajouté quelques bouts, j'ai vu, mais pourquoi il y a autant de développeurs dans ce truc, quoi ? Mais en fait, c'est un peu ça, c'est parce que c'est pas une appli, c'est pas un paquet cadeau, enfin, c'est pas un truc qui est fini, qu'on met dans un paquet cadeau, et puis qu'on te livre, comme ça, quoi. C'est un truc qui vit en permanence, et en fait, ça revient au fait de dire que la maintenance, c'est essentiel, quoi. Enfin, il faut... Il faut avoir des développeurs qui sont toujours sur le coup et qui vont résoudre les bugs, qui vont passer à la suite, qui vont passer à la V2 et c'est le plus important.

• Speaker #0

  Et après il faut des devs qui puissent maintenir et des devs qui puissent développer les V2.

• Speaker #1

  Oui c'est ça, totalement.

• Speaker #0

  C'est pour ça qu'on se retrouve avec des robots.

• Speaker #1

  C'est ça.

• Speaker #0

  Donc voilà, maintenance très importante, il faut le retenir. Et après il y a un point qui est aussi important dans la gestion du dev et du coup du développement informatique. Et ça, ça va dépendre un peu de l'agence avec laquelle vous travaillez ou de la personne que vous avez en face. Mais il faut aussi être capable de choisir la bonne technologie en fonction du client que vous avez en face, que pour nous on a en face, mais de votre projet en tout cas. Parce que, imaginons, vous voulez recréer un système de booking d'appartement. C'est le pitch Airbnb. mais vous voulez je sais pas c'est c'est pas partout dans le monde c'est concentré sur les yvelines et vous faites que des châteaux vous lancez réservation de chambre dans des châteaux dans les yvelines je vous le conseille pas mais le marché marche pas des masses mais du coup on va pas non plus réinventer la roue airbnb ils ont déjà fait le travail d'une certaine expérience utilisateur de d'un certain expérimentateur, d'un certain design et d'une certaine manière de fonctionner. Donc on ne va pas réinventer le système. Parce que là, vous arrivez vraiment avec une volonté plus business qu'une volonté plus technique. Donc, au lieu de se dire on recrée tout de zéro parce qu'en fin de compte on va faire la même chose, on peut s'appuyer sur ce qu'on va appeler des templates, des personnes qui ont déjà fait ce bout de code et qui est disponible en open source, par exemple ce qu'on va appeler les clones aussi. On va pouvoir prendre un clone Airbnb et ensuite retravailler dessus. Donc au lieu de faire 3 mois de dev pour recréer un Airbnb Lite, on va en prendre un mois et demi à customiser pour vous une base déjà existante. Donc ça, ça permet d'avoir quelque chose assez vite et avec un coût moindre. En revanche, on garde le même projet. Vous êtes toujours avec vos châteaux dans les Yvelines, mais je ne sais pas ce que vous avez en tête. Vous voulez changer l'expérience utilisateur au maximum et vous voulez que ça intègre une IA pour proposer les meilleurs châteaux selon les châteaux que vous aimez. Voilà, très bien. Et bien du coup, là, ça va être plus compliqué d'utiliser le clone Airbnb parce qu'il va falloir qu'on rajoute des fonctionnalités customisées. Donc là, ça vaut peut-être plus le coup de partir from scratch, donc du début, pour bien choisir cette technologie, bien poser les bases pour que ensuite, vous allez pouvoir construire. chaque jour, chaque mois de nouvelles fonctionnalités et que ça avance. Donc, hyper important de choisir entre ces deux custom templates à choisir. Et peut-être exemple plus simple, on le voit, on est en train de travailler avec une entreprise dans la mode, qui s'appelle MacWriter, je ne sais pas si je le prononce bien. Elle est là. C'est sur la casquette d'Adrien, pour ceux qui regardent YouTube. Et du coup, on lui fait un site e-commerce sur WordPress, plutôt simple. Et on s'est basé sur une template pour diminuer les coûts de développement au maximum. et d'avancer très rapidement pour qu'on puisse aller on sale pour vendre rapidement. Oui,

• Speaker #1

  c'est sûr. C'est besoin et ne nécessiter pas un développement complexe d'une application. Donc voilà, c'est ce que tu disais. Autant partir sur une template, ça fait vraiment bien le job et c'est moins coûté pour lui. Donc c'est gagnant-gagnant.

• Speaker #0

  C'est ça. Donc non, c'est vraiment un bon... une bonne chose et suite à ça comme on disait si par exemple partait sur du from scratch de zéro faut aussi choisir les bonnes technologies surtout les technologies du moment parce que vous pouvez avoir des technologies qui vont devenir obsolète dans quelques mois quelques années donc ça serait bête de commencer votre projet avec une avec une techno qui va déjà devenir obsolète directement donc souvent faut aussi se renseigner je sais que c'est compliqué pour ceux qui se parlent la technique ou soit vous avez absolument confiance dans le développeur avec lequel vous parlez mais dans les technologies du moment par exemple sur le mobile il y a du flutter qui est assez en ce moment qui est assez réputé on a react native qui fait toujours toujours son trou il est là on utilise ça par exemple donc ça c'est pas mal parce que ça permet de faire des applications ios et android en même temps donc ça réduit les coûts de développement en plus et après si vous voulez vraiment une application spéciale ios spéciale android c'est des technologies précises comme le Swift ou le Kotlin. Et pour le web, en ce moment, on a Next.js qui est quand même pas mal important.

• Speaker #1

  À nous, c'est notre cœur.

• Speaker #0

  C'est notre spécialité. C'est notre spécialité. Donc évidemment qu'on va pousser Next.js. React, c'est du React derrière. Et puis en backend, on a beaucoup de Nest.js ou de Node.js, où c'est assez réputé en ce moment. Il y a une bonne communauté derrière. Là, c'est plus les développeurs qui peuvent vous le dire. Mais il y a beaucoup de monde qui back up ce genre de... de technologie. Donc on peut faire confiance. Par exemple, React, c'est l'équipe de Facebook derrière. Il y a eu Angular à une époque que moi j'ai toujours détesté. Et je ne sais pas si encore aujourd'hui c'est cool. Mais en tout cas, c'était Google derrière. Et Next travaille avec les équipes de Facebook puisque c'est React. Donc c'est quand même des personnes assez importantes dans le milieu tech. Donc on peut leur faire confiance. Et petit taquet pour nos anciens développeurs. le PHP existe encore Symfony etc les gens adorent ça les anciens développeurs adorent ça et nous on déteste comme ça c'est clair ça devient rare j'ai pas encore vu un jeune développeur me dire je me suis fait un PHP ce week-end j'ai adoré ce week-end donc voilà petit taquet pour nos anciens

• Speaker #1

  pour nos anciens c'est top non mais après bon voilà c'est faut avoir ses biais c'est important on est prêt à discuter c'est

• Speaker #0

  comme si vous codiez en cobble, là je parle aux anciens des anciens c'est une technologie qui est morte le système bancaire l'utilise encore beaucoup donc c'est très inquiétant mais voilà non mais c'est On en rigole.

• Speaker #1

  Oui, c'est important d'en rigoler.

• Speaker #0

  Donc voilà, qu'est-ce qu'on peut conclure sur ce podcast, sur ce coût des développements ?

• Speaker #1

  Passer par Biontech.

• Speaker #0

  Par un suivalement. Si je peux dire un petit mot quand même pour vendre notre agence. Nous, en tout cas, on essaye de faire attention. Même on fait attention.

• Speaker #1

  À tous les points qui ont été évoqués.

• Speaker #0

  À tous les points qui ont été évoqués. Évidemment. On va vous conseiller des technologies. C'est à vous de voir. On va vous faire des premiers devis. au maximum de toutes les fonctionnalités que vous voulez. Après, on écoute, on enlève, on revoit notre devis, etc. On est, en termes de tarifs, dans la moyenne du marché, j'ai envie de dire, voire un peu en dessous. Donc, n'hésitez pas à venir faire des devis avec nous. On sera heureux d'en discuter. Et voilà, on fait un peu de tout ça.

• Speaker #1

  On sera toujours heureux d'accueillir de nouveaux projets. C'est magnifique.

• Speaker #0

  C'est un métier, quoi. Donc, il faut retenir, quand vous avez une idée, c'est top. Posez-vous la question des pain points sur vos utilisateurs, des points de difficulté, des points de douleur. Faites des maquettes. Donc, soit avec une agence, soit avec un free, soit avec Beyond the Market. Très important. Une fois les maquettes faites, faites les devis de développement. Comme ça, ce sera beaucoup plus précis. Le développeur, il va savoir où aller. Une fois que le développement est lancé, posez-vous les questions des API qui vont être utilisées,

• Speaker #1

  le coût. Les coûts cachés, les serveurs.

• Speaker #0

  Les serveurs. Est-ce que vous voulez mettre en place des tests approfondis ou pas ?

• Speaker #1

  C'est un choix.

• Speaker #0

  C'est un choix. Et la maintenance, très important pour la suite du projet.

• Speaker #1

  Exactement.

• Speaker #0

  Donc voilà, et après le développeur vous expliquera les stacks techniques, s'il faut mieux partir sur le custom, du template, etc.

• Speaker #1

  C'est un bon résumé. Un bon résumé ? Je pense qu'en écoutant ce podcast, si on a envie de lancer son projet, on est heureux parce qu'on a fait le tour, je pense, un peu sur les points les plus importants pour se lancer. Donc non, non, franchement, je suis content. On est bon. On a respecté notre podcast, notre ligne directive.

• Speaker #0

  Magnifique. Et avec ce petit vent qui arrive dans votre micro, on va vous laisser. On va aller se prendre un petit rosé.

• Speaker #1

  Un peu d'ASN.

• Speaker #0

  Après ce podcast, de manière très délicieuse. Et on pensera à vous si vous avez des questions sur vos projets ou même des devis à faire. N'hésitez pas, on en discute. On est dispo sur LinkedIn.

• Speaker #1

  j'ai toujours rêvé de le faire mais tu parles de rosé donc je vais le dire l'abus d'alcool est dangereux pour la santé j'ai toujours rêvé de le faire faut le rappeler c'est obligatoire d'ailleurs j'ai peut-être sauvé la boîte avec cette annonce on a failli couler donc

• Speaker #0

  n'hésitez pas à venir parler avec nous on partage sur tiktok vous pouvez voir un peu d'autres choses là dessus sur insta et sur youtube principalement vous verrez sur youtube si vous écoutez sur spotify, apple podcast et tout vous verrez sur youtube notre belle tête au soleil, en train de parler surtout sur ce podcast qui est en extérieur comme tu disais on vous met un peu d'ASMR d'ASMR été c'est pas mal on se retrouve pour la semaine prochaine pour un nouveau podcast certainement pas la semaine prochaine, on se retrouve pour le prochain podcast à plus tard salut à tous