--- a/doc/developer.rst	Fri Jun 02 16:25:25 2023 +0200
+++ b/doc/developer.rst	Fri Jun 02 17:38:37 2023 +0200
@@ -17,12 +17,12 @@
 SQLite_ is currently the only supported database, but it is planned to add support for
 other ones (notably PostgreSQL), probably during the development of 0.9 version.
 
-The mapping is done in ``sat.memory.sqla_mapping`` and working with database is done
-through high level methods found in ``sat.memory.sqla``.
+The mapping is done in ``libervia.backend.memory.sqla_mapping`` and working with database is done
+through high level methods found in ``libervia.backend.memory.sqla``.
 
 Before the move to SQLAlchemy, there was a strict separation between database
 implementation and the rest of the code. With 0.9, objects mapping to database can be used
-and manipulated directly outside of ``sat.memory.sqla`` to take profit of SQLAlchemy
+and manipulated directly outside of ``libervia.backend.memory.sqla`` to take profit of SQLAlchemy
 possibilities.
 
 Database state is detected when the backend starts, and the database will be created or
@@ -31,7 +31,7 @@
 To create a new migration script, ``Alembic`` may be used directly. To do so, be sure to
 have an up-to-date database (and a backup in case of troubles), then activate the virtual
 environment where Libervia is installed (Alembic needs to access ORM mapping), go to
-``sat/memory/migration`` directory, and enter the following command::
+``libervia/backend/memory/migration`` directory, and enter the following command::
 
   alembic revision --autogenerate -m "some revision message"
 
@@ -62,7 +62,7 @@
 
 Analysers can be registered by any plugins using ``register_analyser`` method:
 
-.. automethod:: sat.plugins.plugin_pubsub_cache.PubsubCache.register_analyser
+.. automethod:: libervia.backend.plugins.plugin_pubsub_cache.PubsubCache.register_analyser
 
 If no analyser is found, ``to_sync`` is false, or an error happens during the caching,
 the node won't be synchronised and the pubsub service will always be requested.