How you model a relationship b/w classes depends on their logical standing not how they will be implemented in code. For example, association, aggregation, and composition are all implemented in more or less the same way in code. How you model that, however, depends on the logical standing of the interacting classes. Here are some examples:
if two classes work together, you model that as an association.
if one class owns another but can share it with other classes, you model that as an aggregation.
if one class owns another class such that it’s an integral part of the owning class and, thus, its lifetime depends on it, you model that as a composition.
Depending on the logical standing of the relationship of a factory to the product class, IMO, you should model it as a dependency. That the factory stores a reference to the product class (for caching/performance or whatever reason) is an implementation detail that you can clarify using a note if you so choose. So in your example system, you’ll have the CarFactory class with a dependency on RenaultBuilderClio (not CarBuilder as that will be shown as the return type of the create() method, for example).