YT YouTube2Text

YouTube2Text → Transcripts → 7 étapes pour créer une app avec l'IA (+ les PIÈGES à éviter)

7 étapes pour créer une app avec l'IA (+ les PIÈGES à éviter) — Transcript

by Développeur Libre · 4,346 words · 639 segments · language en · Watch on YouTube

Open in transcriber Summarize with AI Download SRT/VTT

Full transcript

0:00Today, anyone can create an application
0:02with AI in just a few hours. But the
0:04problem is, we end up with millions of
0:06applications that are empty on the
0:08inside. Poor architecture, security
0:10flaws, shaky features, and plenty of
0:12hidden bugs we won't see for another 6
0:13months. I've been using AI for 3 years
0:16to develop all kinds of applications.
0:18This ranges from iOS apps and web tools
0:20to landing pages, and I've listed the
0:22seven essential steps to follow to
0:24ensure you build a real app with AI,
0:27and especially the traps that cause
0:29most projects to fail. And you'll see
0:32that step 5 is perhaps the most
0:33critical one. The first step is to
0:36validate the idea before rushing in. A
0:39common mistake I see all the time, and
0:41one I sometimes make too, is that when
0:43we have an idea, we think of two or
0:45three features and jump onto the PC in
0:47Cursor to explain what we want to
0:49develop as an application in a single
0:51prompt, sometimes 20 or 30 lines long.
0:53But I see two problems with that. First
0:56, no choice of tools or specification
0:58of requirements will be made. AI will
1:02choose the languages, frameworks, and
1:04databases for you, and it might suggest
1:06tools that could cost you 20, 30, or
1:08even 50 euros a month when, as it turns
1:10out, you didn't even need them. And the
1:13second problem is that no validation of
1:15requirements will be made. You will end
1:17up creating features that might not
1:19even be necessary and that may provide
1:21no real solution to your problems. And
1:23the solution to this comes in several
1:25stages. The first stage is to validate
1:28the need with the end users. Sometimes,
1:30when I ask the question, people can't
1:32even tell me who the end users are. If
1:35you want to create a tool for your
1:36company, is it for you to manage your
1:37teams? Is it for your teams because
1:40you're going to give them access to
1:42this tool, or is it for your vendors,
1:44your contractors, whatever it may be.
1:46For example, I developed a tool that
1:47helps me manage my YouTube production.
1:50So, the different stages of creation,
1:52partners, invoices to pay for
1:54thumbnails, which video performs best
1:56or attracts the most leads, and so on
1:58and so forth. So, I had to think about
2:01who the end user was going to be. It's
2:04me, certainly, but not only me. There
2:06might also be Axel, my thumbnail maker,
2:08or potentially my clients, like those
2:10to whom I offer the "one day with a
2:12developer" format. And should I include
2:14them on the platform? If so, what do
2:16they need, what extra value does the
2:18tool bring them, and how does it save
2:20them time? And all these are questions
2:22to ask yourself before even starting
2:23development. And that's how I realized,
2:25for instance, that it was pointless to
2:27give access to the tool to the
2:28companies I offer the "one day with a
2:30dev" format, because they already have
2:32their own process. Whereas for Axel, it
2:34actually helps because he uploads all
2:36the thumbnails directly there. There's
2:38no longer a need for a link to a Drive,
2:40he uploads his invoices directly, and
2:42he knows exactly how much I owe him at
2:43the end of every month. So, before
2:46rushing headlong into code or no-code,
2:48define first who your end users are,
2:51second what their real problem is, and
2:54thirdly the features that will actually
2:57be useful to them. Second step, now
2:59that you've understood the needs of
3:00your end users, it will be to scope out
3:02the project and, above all, the
3:03requirement. Because there, once again,
3:05we often want to go too fast, and I
3:07think that is precisely one of the
3:09biggest traps of AI. It's not
3:11necessarily security, as we often see.
3:13We'll talk about that security point
3:15again, by the way, because it's a real
3:16issue. But today, AI is capable of
3:19writing fairly clean code with basic
3:20rules so that your tool is secure, so
3:22that your data cannot be scraped or
3:23that someone cannot access part of the
3:25API without being authenticated. But
3:27for that, you still have to understand
3:29what you're writing and have a minimum
3:30of technical knowledge. Right? To me,
3:32the biggest trap in using AI to develop
3:35an application or tool is the speed at
3:37which it can produce code, and clean
3:39code at that. On top of that, that's
3:40the worst part. I'll take the example
3:42of a friend who used Lovable to create
3:44an internal prospecting tool. So, he
3:46doesn't have a technical background at
3:47all, you know. He's not a dev. With
3:50prompts, he managed to create software
3:52that can be used very easily locally on
3:54his computer. And he literally told me
3:57it was great because the AI adds all
3:58sorts of stuff without you even asking
4:00for it. But the problem with that is it
4:03expands the scope, and it’s the best
4:05way to create a bloated system full of
4:06invisible bugs that can be very costly
4:08in the long run. Actually, it’s a bit
4:11like fast food. Before, when you wanted
4:12to eat, you had to go get meat from the
4:14butcher. You had to go pick your
4:16vegetables from the garden and cook for
4:17an hour. Well today, you just open Uber
4:20and in 30 seconds your food order is
4:22placed and it arrives like magic half
4:25an hour later. Well, AI is pretty much
4:26the same. If you want a button on your
4:29app that gives you a single chart with
4:31a recap of your whole business, well,
4:33one or two prompts with code, it's done
4:35, and it's often done well. That’s
4:38not even the issue, but it’s
4:39precisely this speed of execution and
4:41especially the ease of adding a new
4:43feature. And that’s the trap, because
4:46just like fast food that saves you an
4:47hour a day but makes you lose track of
4:49calories, AI makes you lose track of
4:51what’s actually important for your
4:52application, and so you gorge yourself
4:54again and again, adding anything and
4:56everything. And in the end, you wind up
4:59with an obese app that completely
5:01drowns its core functionality in
5:02details that take up way too much space
5:04, and you end up abandoning the project
5:06after a few weeks. So what's the
5:09solution? The magic solution to all
5:11this is a word you've been hearing
5:13everywhere since the arrival of AI
5:14agents: the PRD. And it's actually a
5:16concept I talk about a lot in the book
5:18I recently released, which gives you a
5:20step-by-step method to build an
5:21application with AI, whether you're a
5:23dev or not. Except that many people are
5:25wrong when they think about the PRD. So
5:27the PRD, for those who don't know, is a
5:29Product Requirement Document. And to
5:32put it simply, that's where we describe
5:34the features, the objectives, and who
5:36the tool or application we are
5:37developing is for. And it will allow
5:40the AI to actually understand exactly
5:42what direction we need to go, what
5:43design we should implement, or how to
5:45build the graphical interface. But the
5:48problem is that far too often, and I
5:50see this every time I talk to someone
5:52who wants to create their SaaS with AI,
5:54we forget the most important section.
5:57Because scoping a project isn't just
5:59saying we want this or that feature
6:00aimed at this or that person. It is
6:03also, and above all, knowing how to say
6:05that this feature is not for now. We'll
6:08keep that detail in mind, but for now,
6:10it's not the priority. And it is
6:12precisely this entire out-of-scope
6:13section that is too often forgotten in
6:15the PRD. I found a simple trick to keep
6:18from getting sidetracked when I develop
6:20an application with AI: in the cloud.md
6:22file, I add an instruction forbidding
6:24Claude from developing any new feature
6:26that isn't in the PRD. That way, every
6:30time I'm tempted to add a new feature
6:32or idea, it adds it directly to the
6:34backlog and actually explains that it
6:36can't develop it until I've explicitly
6:38lifted the ban. This way, I end up with
6:41a backlog of features to develop later
6:43that aren't a priority for now. So,
6:46from now on, try to implement this
6:48technique to avoid going out of scope
6:50as much as possible and, above all,
6:52ending up with an app cluttered with
6:54features everywhere. Now that you’ve
6:57defined the project scope, know exactly
6:59what you’re going to build, and
7:01especially the problem you’re solving
7:02—because that’s what's written in
7:04the PRD—we can move on to the third
7:06step: choosing the right level of
7:08ambition. Because, as we were just
7:10talking about earlier, there’s
7:12security, optimization, and all that
7:13jazz. Today, AI is capable of writing
7:16secure code, protecting a database from
7:18scraping, or alerting you when secret
7:20keys are exposed. But the fact that it
7:23knows how to do all that, write clean
7:25code, and set up a fully comprehensive
7:28architecture worthy of software used by
7:30millions of users, I think is also a
7:32handicap because, again, if you don't
7:34scope it, it can quickly overcomplicate
7:36a project. And I see plenty of LinkedIn
7:38posts on this subject explaining that
7:40AI put way too many things in place for
7:41a fairly simple project. Let me take a
7:43very simple example. Once, I wanted to
7:45create a landing page for one of my
7:46apps on the App Store, and I admit I
7:48wanted to be a bit quick with the brief
7:50. I gave it to the AI and just
7:52explained that it was a landing page to
7:54promote an iOS app, and so on and so
7:55forth. And I launched Claude Code in
7:57parallel with something else I was
7:58doing on the side, hoping to save a
7:59little time. Except when I came back
8:01half an hour later, he had set up an
8:03entire, super complete architecture for
8:06me with a server, databases, automatic
8:08deployment for future updates, and
8:10everything that goes with it. So, okay,
8:12that's cool, but I didn't need any of
8:15that at all. The site was static; I
8:17didn't need authentication, and I
8:18didn't need a connection to a database.
8:21Basically, it was a super basic site,
8:23and Claude had set up an architecture
8:25that was far too complex for this
8:27project, which would have just wasted
8:29my time later on if I had kept it. And
8:31that is why the third step is so
8:33incredibly important. You have to
8:35choose the right level of ambition for
8:37your project. If you want to build a
8:40small internal tool that only you are
8:42going to use locally, if it's a side
8:44project and it wouldn't be a tragedy if
8:46you lost all the data after a few weeks
8:48, the stakes are not the same as if you
8:50aim to create an ERP for a company with
8:52100 employees, 10 projects in parallel,
8:54and millions in revenue to track.
8:57Alright, now that you've scoped out the
8:59project well, and you know where you
9:01want to go and what your goals are for
9:03your app, we can finally move on to
9:05building it. And here, too, there's a
9:07trap, because too often we are tempted
9:09to try and move too fast. We tell
9:11ourselves we've prepared the ground
9:13well, like a coach before a World Cup
9:14final, that we've studied our subject
9:16well and are ready to roll out the plan
9:18and put all our strategies into
9:19practice. Except, well, you and I both
9:21know that even if you're on top of your
9:23game on paper, a lot can happen during
9:24a match—and not just in the final,
9:26either. So the goal now that your
9:29roadmap is squared away is to carry out
9:31each step one by one, but verifying
9:33that everything went well before moving
9:35on to the next stage. Now, I know a lot
9:38of people will tell you that you
9:40absolutely must read every line of code
9:42the AI produces and validate it before
9:44integrating it into your app. I don't
9:46necessarily agree with that, and for
9:48two reasons. First, because if we
9:50follow that principle, we're implying
9:52that only developers should have the
9:54right to use AI to build an app. Or
9:56even a website. And secondly, because
9:58if we do that, we spend almost as much
10:00time reviewing the code as we would
10:02have spent writing it ourselves without
10:05using AI. And we have to understand
10:07that today, AI—regardless of the
10:09model, that doesn't really matter—can
10:10do some things very well without us
10:12necessarily needing to review it, and
10:14other things a bit less well, which
10:16require our full attention. For example
10:18, to simplify, everything related to
10:20the front-end—that is, the visible
10:22part of the app, like the screens, the
10:24design, the animations, the buttons,
10:26etc.—is what AI masters best. It is
10:28almost completely autonomous in that
10:29regard. A non-developer will be able to
10:31recreate almost any interface with AI
10:33without reading a single line of code.
10:35However, when it comes to database
10:38connections, memory resource
10:40optimization, error handling for poorly
10:42formatted data, or what happens during
10:45a network outage or similar issues?
10:47Well, that is much harder to foresee,
10:49and you can only assess the damage once
10:51it’s done if you don’t at least
10:52check the code produced by the AI or
10:54have some minimum level of expertise on
10:56the subject. And it's logical when you
10:58think about it; it’s precisely
10:59because these problems aren't visible
11:01that an average user won't be able to
11:02predict them. Anyone can look at an
11:04interface and say whether or not it
11:06looks as expected, if it has the right
11:09buttons with the right colors, and so
11:11on. So, that's why today I remain
11:13convinced that even if coding an
11:15application, a SaaS, or an internal
11:17tool is within everyone's reach, the
11:19ambition you want to put behind it will
11:21determine whether or not you need a
11:23tech profile to support you on that
11:26project. Let's move on to the 5th step,
11:29which is more of a set of errors to
11:30avoid than a step in its own right, and
11:32which follows directly from everything
11:34we said in the previous stage. Even
11:37though there could be many others, I
11:39have listed four major mistakes that
11:40most new developers using AI make. The
11:43first mistake is failing to verify who
11:45has permission to see what. If you have
11:48an application that implements
11:49authentication, you know that some
11:51parts of the app shouldn't be
11:52accessible, or should only be
11:53accessible to a specific portion of
11:54your audience. Except sometimes the
11:58interface might hide a button or a page
12:00without the database actually denying
12:02access to someone who bypasses the
12:03application. And with certain URLs or
12:07specific API calls, one could easily
12:09bypass the site and gain access to data
12:11that is normally confidential. I often
12:14use the example of the Park4Night app,
12:16where you are required to have a
12:17premium account to access all the spots
12:19where you can park a camper van. But by
12:22searching a bit, you can quite easily
12:23find an endpoint on the web that gives
12:25access to the entire database of spots
12:27for free and without authentication. So
12:29, this is a known issue. The developers
12:31even added a small line at the top of
12:33the API to indicate that they are aware
12:35of this problem and that we are not
12:36allowed to use that data. But the fact
12:38is that with AI, well, it's a problem
12:39that is becoming more and more
12:40recurrent. For example, if you use a
12:43tool like Supabase to manage these
12:45databases, you have what is called
12:46row-level security, which ensures that
12:48every row in the database is protected
12:50by access rights. If you are not
12:53authenticated with the right type of
12:54account, the database returns either
12:56nothing or an error. And so this helps
12:58protect the data against potential
13:00attacks. The second mistake is simply
13:02sharing a secret key in the code or on
13:04GitHub. Boom, the door is wide open.
13:06Because when you use third-party
13:07services like a database, for example,
13:09you will inevitably need what are
13:11called secret keys that allow your
13:13application to connect to these
13:14services. Except that if, by clumsiness
13:17, you paste a secret key where it
13:19shouldn't be, well, everyone can have
13:21access to it and obtain data that is,
13:23once again, confidential. And the
13:25problem is that for a non-developer, it
13:28can go completely unnoticed. Personally
13:30, my AI always warns me. It prevents me
13:33from copy-pasting keys, even into the
13:34Claude chat, which in itself is only on
13:36my computer. But if the PRD is not
13:39precise enough about your project's
13:41ambitions, Claude or any agent could
13:43potentially let a secret key slip
13:44through and disclose it unintentionally
13:46. The third mistake is not knowing what
13:49happens when things go wrong. Your
13:52application probably needs to have
13:53access to the network. But what happens
13:55if there is a network outage? Or if a
13:58form is filled out incorrectly, or if a
14:00server is down? Often, when developing
14:02with AI, the application works in a
14:04demo, but it can crash in production
14:06and sometimes, it can even lose highly
14:09sensitive data. So, to solve this
14:11problem, we will come back to it in
14:12more detail in step 6. And finally, the
14:154th problem is often maintenance. We
14:17add dependencies, meaning software,
14:20libraries, and external tools to our
14:22project to, for example, connect to a
14:24database or link other tools. Anyway,
14:27actually all these dependencies we add,
14:29when they get updated, sometimes it
14:31breaks our project, and it's impossible
14:33to know where it comes from when you're
14:35not a developer and don't have a
14:37minimum of technical knowledge. So, I
14:39assure you, we will be able to limit
14:42all these problems, in a way, thanks to
14:44step 6. But I’m taking a quick detour
14:48, because if you are an SME manager and
14:50today you need to create your own
14:52internal tool to manage your business,
14:54understand which project brings you the
14:56biggest margins, or set up automated
14:58reminders or follow-ups, but you
15:00currently manage this with 15
15:01spreadsheets, three email inboxes, and
15:03Drive folders, not to mention physical
15:05documents that get lost after 3 days...
15:07Well, I might be able to help you
15:09develop a custom solution that will
15:11increase productivity for you and your
15:13staff, obviously, to free up more time
15:16for your company's strategic thinking,
15:19where you can really add the most value
15:21. So if you recognize yourself in this,
15:23there is a link in the description that
15:25will allow you to book a quick
15:26half-hour appointment so that I can
15:28fully understand your situation and
15:29tell you whether or not I can actually
15:31help you. And if I can’t, well, I
15:33will do my best to advise you and
15:35recommend someone who better matches
15:37your needs. Step 6 now is to test every
15:41possible configuration before
15:43considering your product finished. I
15:46know, it’s perhaps the most annoying
15:48step, but it is above all the most
15:50important. The trap, in fact, is
15:51telling yourself, "It works for me, so
15:53it will definitely work for others."
15:55And that, how many times have I seen
15:57non-tech profiles do that? An
15:59AI-generated application almost always
16:01looks like it works perfectly, and
16:03that’s normal because today AI agents
16:05have almost all the necessary tools to
16:08check what they have done locally and
16:10verify that it functions. For example,
16:12Claude can test an iOS application by
16:15launching the simulator itself and
16:17taking screenshots to verify if it
16:19works visually. But that, precisely,
16:21might be a huge trap, and in fact, it's
16:23what we call the "happy path." The
16:25perfect path, the actions your ideal
16:28user will take: the one who perfectly
16:30understands how to use the tool and
16:32fills in exactly what needs to be
16:34filled in. So, precisely, the first
16:36point to test is every possible case
16:38that falls outside the happy path. So,
16:41what happens if there is a typo? What
16:43happens if you leave a field blank? If
16:45the network is cut in the middle of an
16:46action. AI will often tend to skip all
16:49of that and fail to handle these cases.
16:52Next, you need to test your app with
16:54real data, because demo data is nice
16:57and all, but what happens if you have
17:00300 projects to load at once? Do the
17:03data display correctly? Do the filters
17:06apply properly to all projects, and so
17:08on and so forth? And all of that, in a
17:10demo where you only have 5 or 10
17:12projects displayed, well, it doesn't
17:13necessarily show up. Because all that,
17:15well, likewise, the AI won't
17:17necessarily know how to handle it or
17:18won't necessarily think to manage every
17:20scenario. And you can only really
17:23predict if the app will be operational
17:24and optimized in these situations by
17:26getting your hands into the code, or by
17:28testing it directly in the field. But
17:30it would be a shame to realize, just as
17:32you're getting a client to sign a quote
17:34, that the application crashes due to
17:35an error that's impossible to reproduce
17:37with the demo. And a third point that
17:38absolutely must be tested: access
17:40rights. We were just talking about it
17:42before with the Park Fortnite
17:43application. Verify by creating several
17:45different accounts that you only have
17:47access to what you are supposed to see
17:49in the application. Try to poke around
17:52your application a little bit in every
17:53way to be sure that your rights are
17:55strictly limited, and so on. But once
17:57again, unfortunately, that doesn't
17:59protect everything because, as we said,
18:01the application might visually hide
18:03certain parts that would still be
18:05accessible by having the right URLs and
18:07doing a bit of reverse engineering on
18:09the app or site. And so, for that, you
18:11necessarily have to get your hands into
18:12the code to be able to verify it. So
18:14finally, the message to remember for
18:16verifying that your app is functional
18:17and "finished," in quotes, is to test
18:19as many cases as possible. But
18:22unfortunately, that's not enough,
18:23because as long as you lack the
18:24experience and especially the technical
18:26skill to understand how things work
18:27behind a beautiful application, it will
18:29remain very complicated to anticipate
18:31every possible scenario. And finally,
18:33the 7th and last step: your app is
18:35functional. You've tortured it a little
18:38bit in every way to eliminate as many
18:39bugs and security flaws as possible.
18:42And it's finally time to publish it.
18:44But here again, be careful, because
18:46there's a trap. We often think that
18:48publishing is just the moment you ask
18:49Claude to, say, publish my website on
18:51such-and-such domain name, and that
18:53it's sort of the finish line and then
18:55everything is over. But actually, it's
18:57quite the opposite; it's often where
18:59everything begins, because there are
19:00several things to do at the moment, or
19:02rather just before, publishing your
19:03application, whether it's a mobile app,
19:04an internal tool, or a SaaS, it doesn't
19:06matter. Before publishing, first of all
19:09, back up your data. This is true for
19:11the very first release, but also for
19:13all the future updates you will make.
19:15It's super important. Next, you must
19:17separate the test environment from the
19:19production environment. Now, production
19:21, for those who don't know, is the
19:23version of the site accessible to all
19:25your users, and the test version is
19:27what you see when you're developing new
19:28features that aren't yet available on
19:30your computer. Except that too often,
19:33when working with AI, these two
19:34environments get mixed up, and you end
19:36up with projects named "test" in the
19:38production version, or worse, you
19:40delete data thinking it's nothing
19:41because you're just on the demo version
19:43. Except that on Monday morning, when
19:45all your users log back in, well,
19:47there's nothing left. And finally,
19:49choose hosting that is the right size,
19:51that can handle the right level of
19:53concurrent connection load, that can
19:55support enough users, and above all,
19:57store enough data for your needs. Now,
20:00a quick tip for during the publication
20:02process. If you can, start deploying
20:05your application gradually. Start with
20:08two or three users who actually use
20:10your product to verify that everything
20:12is working correctly, and then that way
20:14you can continue the deployment to the
20:16rest of your users. So in the end, if
20:20we recap everything we've just said,
20:21the first step is to define who these
20:23end users are, to meet them, and to
20:25understand the problem you're going to
20:26solve. That is super important. Second,
20:30frame the project with a real set of
20:31specifications, or rather what we now
20:33call a PRD. Third, choose the right
20:36level of ambition for your project to
20:38implement the right architecture and
20:40tools without ending up with a
20:42convoluted mess or 15 subscriptions
20:44costing you over 1,000 bucks a year.
20:46Fourth, build your application
20:48step-by-step by verifying every phase
20:50of the project and testing as many
20:51cases as possible. Fifth, check the
20:54blind spots like permissions, access,
20:56secret keys, error handling, or
20:58maintenance. Sixth, test before you
21:00consider the app to be finished. And
21:03finally, deploy the application little
21:05by little and in stages to ensure
21:07everything works well without risking
21:09the loss of important data. If you have
21:11any questions regarding all of this,
21:13don't hesitate to ask them in the
21:14comments; I will answer all questions.
21:16I could provide you with additional
21:17details. And if you are an SME manager
21:19and need a custom internal tool, the
21:21link is in the description. We can have
21:24a quick call; it’s absolutely
21:25non-binding. I’ll give you an initial
21:27diagnostic of your organization, share
21:28some advice, and we’ll see if we can
21:30work together or not. This was Quentin,
21:32and I’ll see you very soon for
21:33another video.

About this transcript

This page contains the full transcript of 7 étapes pour créer une app avec l'IA (+ les PIÈGES à éviter) by Développeur Libre, generated from the public captions YouTube serves with the video. The transcript has 4,346 words across 639 segments, with the original timestamps preserved so you can click any line to jump to that moment in the embedded player.

What you can do with it

Use the transcript to take notes, quote the speaker, build a study guide, generate a summary with ChatGPT or Claude via the YouTube Summary tool, or export it as a timed subtitle file with YouTube to SRT. You can also re-open it in the transcriber to choose a caption track available on the video.

Free YouTube transcript tool

YouTube2Text is a free YouTube transcript generator — no signup, no daily limit. Paste any YouTube link and get the full transcript instantly, with timestamps, click-to-jump, caption language selection, AI prompts for ChatGPT, Claude, and Gemini, and exports to TXT, SRT, VTT, or Markdown.