My philosophy "always private, unless it needs to be public".

:-) Sounds silly, but it actually does mirror how I program.

Languages such as C++ and Java have more modes than just private  and public,
and part of what I consider good programming is to limit the visibility of
an item as much as possible. Therefore, I always start with private and
relax this as needed. So too with VBA. Make it private until you need to
access it from outside its module.

For variables (attributes, or whatever you like to call them) in modules,
consider always keeping them private and writing access functions  and subs
to get and set them if they need to be accessed from outside the module.

Note ,,, this is not a rule, it's a guideline. Feel free to ignore it when
circumstances suggest that public  variables would be a better way to go.

but usually Set Option Private in the
module, and then make most things Public. This restricts to the project
but can be used from there modules.

Do I understand well that if one sub wants to access another sub,
they could be both written as private  as long  as they are written in
the same module?
Then I shall reorganize my modules to put in the same modules the
subs that are used in the same process and not needed anywhere else.

If I am right, don't bother to reply :-)

When you write:
"For variables (attributes, or whatever you like to call them) in
modules, consider always keeping them private and writing access
functions and subs to get and set them if they need to be accessed
from outside the module."
I muss confess that I do not quite understand as well, probably
because I did not meet the problem, or had the need for it.
But I'll save your message and come back to it when I need it.

At the stage where I am, I would never ignore the experienced
guidelines from someone generous enough to reply to my questions!

Yes, you are right in your understanding about how private  works. However,
don't be afraid of "public". It's fine.

Try to treat your modules a bit like you'd treat classes or objects in
object-oriented programming. In other words, try to encapsulate a single
subject in a module with all the variables that hold its state (private),
all the routines that allow other modules to get it to do things (public)
and any needed "helper" subs and functions  (private).

Smaller projects don't need to be broken up like this, but larger projects
definitely benefit.

But anyway ... don't worry about having cross-module calls. They're fine,
and often are easier to understand than a single large module with lots of
fairly unrelated subs in it.

Do, however, get into the habit of using "dot" notation when referring to a
routine in a different module. E.g. "Call BankAccounts.Withdraw (xxx)", so
that (1) you know exactly where the sub is, and (2) your subs and functions
can have simple "action" names.

I also recommend that you get into the habit of using the "Call" keyword on
calls to subs, rather than just putting the name of the sub; and also that
you always enclose parameter lists in parentheses for calls to subs, like
you have to do for calls to functions. Neither is required by the compiler,
but IMHO they make the code more readable (especially the parentheses round
the parameters).

Thanks for being so "explicit".
Not only did you answer  my question, but you answered another one that
I did not dare to ask:
combining your two replies, I now understand the statements Option
Explicit and Option Private that I saw often and did not know what
they were for :-) .

And I learned much more than what I was asking, but I have become so
eager to learn, I would certainly not complain!