What you're observing is a common constraint in some educational projects or simplified frameworks like SQLiteLight2.
The database must contain at least one row so that certain queries (often a SELECT or a fetch) don't cause errors.
Add a "dummy" person during initialization. You can then delete this row as soon as you add a real person.
By doing this, you respect the SQLiteLight2 constraint (at least one row), but you keep the database "logically empty."
Before performing a SELECT, test if the table contains rows: SELECT COUNT(*) FROM personnes;
If the result is 0, you avoid running code that assumes there is data.
This requires modifying your program to handle the "empty" case.
In conclusion, the simplest and most robust solution is to insert a dummy row at startup.
You start with a technically "non-empty" database, but you treat this row as a placeholder. As soon as you add a real person, you can delete or ignore that entry.